home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Standards 1994 January / InfoMagic Standards - January 1994.iso / ccitt / 1988 / troff / 7_5_01.tro < prev    next >
Text File  |  1991-12-13  |  68KB  |  3,075 lines
  1. .rs
  2. .\" Troff code generated by TPS Convert from ITU Original Files
  3. .\"                 Not Copyright ( c) 1991 
  4. .\"
  5. .\" Assumes tbl, eqn, MS macros, and lots of luck.
  6. .TA 1c 2c 3c 4c 5c 6c 7c 8c
  7. .ds CH
  8. .ds CF
  9. .EQ
  10. delim @@
  11. .EN
  12. .nr LL 40.5P
  13. .nr ll 40.5P
  14. .nr HM 3P
  15. .nr FM 6P
  16. .nr PO 4P
  17. .nr PD 9p
  18. .po 4P
  19.  
  20. .rs
  21. \v | 5i'
  22. .sp 1P
  23. .ce 1000
  24. \v'12P'
  25. \s12FASCICLE\ VII.5
  26. \v'4P'
  27. .RT
  28. .ce 0
  29. .sp 1P
  30. .ce 1000
  31. \fBRecommendations T.65\(hyT.101, T.150\(hyT.390\fR \v'2P'
  32. .ce 0
  33. .sp 1P
  34. .ce 1000
  35. \fBTERMINAL\ EQUIPMENT\ AND\ PROTOCOLS\fR 
  36. .EF '%     \ \ \ ^''
  37. .OF ''' \ \ \ ^    %'
  38. .ce 0
  39. .sp 1P
  40. .ce 1000
  41. \fBFOR\ TELEMATIC\ SERVICES\fR 
  42. .ce 0
  43. .sp 1P
  44. .LP
  45. .rs
  46. .sp 29P
  47. .ad r
  48. BLANC 
  49. .EF '%     \ \ \ ^''
  50. .OF ''' \ \ \ ^    %'
  51. .ad b
  52. .RT
  53. .LP
  54. .bp
  55. .LP
  56. \fBMONTAGE:\fR p. 2 = PAGE BLANCHE
  57. .sp 1P
  58. .RT
  59. .LP
  60. .bp
  61. .sp 2P
  62. .LP
  63. \fBRecommendation\ T.65\fR 
  64. .RT
  65. .sp 2P
  66. .ce 1000
  67. \fBAPPLICABILITY\ OF\ TELEMATIC\ PROTOCOLS\ AND\ TERMINAL\ CHARACTERISTICS\fR 
  68. .EF '%    Fascicle\ VII.5\ \(em\ Rec.\ T.65''
  69. .OF '''Fascicle\ VII.5\ \(em\ Rec.\ T.65    %'
  70. .ce 0
  71. .sp 1P
  72. .ce 1000
  73. \fBTO\ \fR \fBCOMPUTERIZED\ COMMUNICATION\ TERMINALS\ (CCTs)\fR 
  74. .ce 0
  75. .sp 1P
  76. .ce 1000
  77. \fI(Melbourne, 1988)\fR 
  78. .sp 9p
  79. .RT
  80. .ce 0
  81. .sp 1P
  82. .LP
  83.     The\ CCITT,
  84. .sp 1P
  85. .RT
  86. .sp 1P
  87. .LP
  88. \fIconsidering\fR 
  89. .sp 9p
  90. .RT
  91. .PP
  92. (a)
  93. that there is an increasingly growing base of
  94. computerized communication terminals, such as communicating personal
  95. computers;
  96. .PP
  97. (b)
  98. that Administrations will require provisions to enable these devices to 
  99. access CCITT\(hydefined services, such as telematic services; 
  100. .PP
  101. (c)
  102. that communication of these devices with each other
  103. may use provisions specified for communication within telematic services;
  104. .PP
  105. (d)
  106. that such devices may, due to their adaptive nature, require, in some areas, 
  107. different protocols and terminal characteristics than existing telematic 
  108. terminals; 
  109. .PP
  110. (e)
  111. that the various telematic services are defined in the F\(hySeries of Recommendations; 
  112. .PP
  113. (
  114. f
  115. )
  116. that the reference model for open systems
  117. interconnection is defined in the X\(hy200\(hySeries of Recommendations;
  118. .PP
  119. (g)
  120. that the various telematic protocols and terminal
  121. characteristics are defined in the T\(hySeries of Recommendations;
  122. .PP
  123. (h)
  124. that there is a requirement to assess the
  125. applicability of the protocols and terminal characteristics defined in the
  126. CCITT telematic recommendations to computerized communication terminals;
  127. .sp 1P
  128. .LP
  129. \fIunanimously declares the view\fR 
  130. .sp 9p
  131. .RT
  132. .PP
  133. that the following technical provisions determine the
  134. applicability of protocols and terminal characteristics specified in CCITT
  135. Telematic Recommendations to Computerized Communication Terminals.
  136. \v'1P'
  137. .sp 1P
  138. .ce 1000
  139. CONTENTS
  140. .ce 0
  141. .sp 1P
  142. .sp 2P
  143. .LP
  144. 1
  145.     \fIScope\fR 
  146. .sp 1P
  147. .RT
  148. .sp 1P
  149. .LP
  150. 2
  151.     \fICharacteristics and model\fR 
  152. .sp 9p
  153. .RT
  154. .LP
  155.     2.1
  156.     Definition
  157. .LP
  158.     2.2
  159.     Characteristics
  160. .LP
  161.     2.3
  162.     General model
  163. .LP
  164.     2.4
  165.     Minimum capability
  166. .sp 1P
  167. .LP
  168. 3
  169.     \fIAccess to the Teletex service\fR 
  170. .sp 9p
  171. .RT
  172. .LP
  173.     3.1
  174.     General
  175. .LP
  176.     3.2
  177.     Characteristics
  178. .LP
  179.     3.3
  180.     Applicability of the relevant CCITT Recommendations
  181. .LP
  182.     3.4
  183.     Access methods
  184. .bp
  185. .sp 1P
  186. .LP
  187. 4
  188.     \fIAccess to the Group 3 facsimile service\fR 
  189. .sp 9p
  190. .RT
  191. .LP
  192.     4.1
  193.     General
  194. .LP
  195.     4.2
  196.     Characteristics
  197. .LP
  198.     4.3
  199.     Applicability of the relevant CCITT Recommendations
  200. .sp 1P
  201. .LP
  202. 5
  203.     \fIAccess to the Group 4 facsimile service\fR 
  204. .sp 9p
  205. .RT
  206. .sp 1P
  207. .LP
  208. 6
  209.     \fIAccess to the mixed\(hymode option of the Teletex service\fR 
  210. .sp 9p
  211. .RT
  212. .sp 1P
  213. .LP
  214. 7
  215.     \fIAccess to the videotex service\fR 
  216. .sp 9p
  217. .RT
  218. .LP
  219.     7.1
  220.     General
  221. .LP
  222.     7.2
  223.     Characteristics
  224. .LP
  225.     7.3
  226.     Applicability of the relevant CCITT Recommendations
  227. .sp 1P
  228. .LP
  229. 8
  230.     \fIAccess to MHS\fR 
  231. .sp 9p
  232. .RT
  233. .LP
  234.     8.1
  235.     General
  236. .LP
  237.     8.2
  238.     Characteristics
  239. .LP
  240.     8.3
  241.     Applicability of the relevant CCITT Recommendations
  242. .sp 1P
  243. .LP
  244. 9
  245.     \fIAccess to the directory service\fR 
  246. .sp 9p
  247. .RT
  248. .LP
  249.     9.1
  250.     General
  251. .LP
  252.     9.2
  253.     Characteristics
  254. .LP
  255.     9.3
  256.     Applicability of the relevant CCITT
  257. Recommendations
  258. \v'6p'
  259. .sp 2P
  260. .LP
  261. \fB1\fR     \fBScope\fR 
  262. .sp 1P
  263. .RT
  264. .PP
  265. 1.1
  266. This Recommendation addresses the applicability of the protocol and terminal 
  267. characteristics specified in CCITT\(hydefined Recommendations to 
  268. Computerized Communication Terminals (CCTs). It should be observed that the
  269. \*Qadaptive\*U (as opposed to dedicated) nature of CCTs calls for, in certain
  270. areas, more flexibility, but without undue degradation of capabilities. The
  271. issues of flexibility versus degradation of capabilities strongly influenced
  272. the proposals made in this Recommendation.
  273. .sp 9p
  274. .RT
  275. .PP
  276. 1.2
  277. This Recommendation specifies how the various telematic
  278. Recommendations may be used, and any additional requirements, to enable
  279. computerized communication terminals to access the various telematic services. 
  280. It is noted that while this Recommendation is applicable to CCTs only when 
  281. accessing telematic services, consideration may be given to the use of the
  282. technical aspects of this Recommendation if CCTs communicate with each other
  283. utilizing the telematic protocols.
  284. .PP
  285. 1.3
  286. Section 2 describes the characteristics of computerized
  287. communication terminals. The remaining sections define how the relevant
  288. telematic Recommendations may be used to enable CCTs to access the telematic
  289. services.
  290. .PP
  291. 1.4
  292. Figure 1/T.65 shows various methods for CCTs to access the
  293. telematic services which are described 
  294. in \(sc\(sc\ 3 to\ 9.
  295. .PP
  296. Three methods are proposed:
  297. .LP
  298.     i)
  299.     access to and from a telematic service via service access
  300. facility (SAF) (see \(sc\ 3.4.2, for example);
  301. .LP
  302.     ii)
  303.     direct access from and to a telematic service;
  304. .LP
  305.     iii)
  306.      direct access from a CCT to a telematic service, reverse access via SAF 
  307. (see \(sc\ 3.4.3, for example). 
  308. .sp 2P
  309. .LP
  310. \fB2\fR     \fBCharacteristics and model\fR 
  311. .sp 1P
  312. .RT
  313. .sp 1P
  314. .LP
  315. 2.1
  316.     \fIDefinition\fR 
  317. .sp 9p
  318. .RT
  319. .PP
  320. The term Computerized Communication Terminal (CCT) refers to a
  321. device or equipment, which may be portable, with a processor and communication 
  322. facility, typically a user work station, which permits entry of various 
  323. applications and which can access CCITT\(hydefined services, such as telematics, 
  324. as prescribed in this Recommendation. 
  325. .bp
  326. .RT
  327. .LP
  328. .rs
  329. .sp 31P
  330. .ad r
  331. \fBFigure 1/T.65, p.1\fR 
  332. .sp 1P
  333. .RT
  334. .ad b
  335. .RT
  336. .sp 1P
  337. .LP
  338. 2.2
  339.     \fICharacteristics\fR 
  340. .sp 9p
  341. .RT
  342. .PP
  343. Computerized communication terminals differ in certain
  344. characteristics from telematic terminals. The following subsections identify
  345. the characteristics of CCTs. Characteristics specific to each case of the
  346. access to telematic services are given in \(sc\(sc\ 3 to\ 9.
  347. .RT
  348. .sp 1P
  349. .LP
  350. 2.2.1
  351.     \fICapability\fR 
  352. .sp 9p
  353. .RT
  354. .PP
  355. A CCT maybe used to access the telematic services. The provisions in this 
  356. Recommendation provide a basic level of compatibility between CCTs and 
  357. the telematic services. 
  358. .RT
  359. .sp 1P
  360. .LP
  361. 2.2.2
  362.     \fIProtocols\fR 
  363. .sp 9p
  364. .RT
  365. .PP
  366. In general, CCTs will use OSI protocols defined in the X.200\(hySeries 
  367. of Recommendations, but configured to meet the requirements defined in 
  368. the 
  369. relevant T\(hySeries of Recommendations. Exceptions include the cases of 
  370. access to the non\(hyOSI\(hybased telematic services, where the relevant 
  371. T\(hySeries of 
  372. Recommendations apply.
  373. .RT
  374. .sp 1P
  375. .LP
  376. 2.2.3
  377.     \fITerminal requirements\fR 
  378. .sp 9p
  379. .RT
  380. .PP
  381. In general, the relevant T\(hySeries Recommendations for terminal
  382. requirements apply. The details specified to each access to telematic services, 
  383. and any additional (or relaxed) requirements are specified in \(sc\(sc\ 
  384. 3 
  385. to\ 9.
  386. .bp
  387. .RT
  388. .sp 1P
  389. .LP
  390. 2.3
  391.     \fIGeneral model\fR 
  392. .sp 9p
  393. .RT
  394. .PP
  395. A model for CCTs accessing telematic services based on OSI is given in 
  396. Figure\ 2/T.65. The model identifies the relevant Recommendations applicable 
  397. to each level in the OSI layers, for each case of access to telematic services. 
  398. In particular, two sets of protocols are identified for access to OSI\(hybased 
  399. telematic services:
  400. .RT
  401. .LP
  402.     a)
  403.      A set of OSI protocols common to most accesses to telematic services 
  404. is identified for the lower layers up to and including the session 
  405. kernel in the session layer. The corresponding CCITT Recommendations required 
  406. are identified. 
  407. .LP
  408.     b)
  409.      Above the common set of protocols, additional session layer functional 
  410. units based on Recommendations\ X.215/X.225 are identified, together with 
  411. any Recommendations required for each of the cases of the access to 
  412. telematic services.
  413. .PP
  414. There are telematic services which require the use of
  415. non\(hyOSI\(hybased protocols. In these cases, the common set of protocols 
  416. may not be applicable and the relevant T\(hySeries Recommendations must 
  417. be used. 
  418. .LP
  419. .rs
  420. .sp 39P
  421. .ad r
  422. \fBFigure 2/T.65, p.\fR 
  423. .sp 1P
  424. .RT
  425. .ad b
  426. .RT
  427. .LP
  428. .bp
  429. .sp 1P
  430. .LP
  431. 2.4
  432.     \fIMinimum capability\fR 
  433. .sp 9p
  434. .RT
  435. .PP
  436. For a CCT to access an OSI\(hybased telematic service it must support all 
  437. the following capabilities, and any additional capability required for 
  438. each case of access to telematic service as prescribed in \(sc\(sc\ 3, 
  439. 5, 6, 7, 8 
  440. and\ 9:
  441. .RT
  442. .LP
  443.     a)
  444.      The appropriate network capability as prescribed in \(sc 3 of Recommendation\ 
  445. T.70. 
  446. .LP
  447.     b)
  448.     X.214/X.224 Class 0 Transport procedure.
  449. .LP
  450.     c)
  451.     X.215/X.225 Kernel; together with half\(hyduplex, or
  452. full\(hyduplex functional units.
  453. .PP
  454. \fINote\fR \ \(em\ The applicability of the minimum capability to videotex 
  455. access requires further study. 
  456. .sp 2P
  457. .LP
  458. \fB3\fR     \fBAccess to the Teletex service\fR 
  459. .sp 1P
  460. .RT
  461. .sp 1P
  462. .LP
  463. 3.1
  464.     \fIGeneral\fR 
  465. .sp 9p
  466. .RT
  467. .PP
  468. The 
  469. access of CCTs to the Teletex service
  470. is a common case of communication with an OSI\(hybased telematic service 
  471. due to the well defined 
  472. nature of Teletex. The following sections describe the characteristics 
  473. of such an access and specify how the various Teletex\(hyrelated Recommendations 
  474. may be 
  475. used.
  476. .RT
  477. .sp 1P
  478. .LP
  479. 3.2
  480.     \fICharacteristics\fR 
  481. .sp 9p
  482. .RT
  483. .PP
  484. 3.2.1
  485. From the technical point of view, CCTs will be able to
  486. establish communications directly with a Teletex device and exchange documents 
  487. on a real\(hytime, end\(hyto\(hyend basis without the use of conversion 
  488. facilities. 
  489. .sp 9p
  490. .RT
  491. .PP
  492. 3.2.2
  493. As far as possible, CCT access to the Teletex service should be
  494. done via message handling systems. The technical implementation is a national 
  495. matter. 
  496. .PP
  497. 3.2.3
  498. CCTs may not necessarily be available continuously to receive
  499. incoming calls. However, when a CCT is available it will be technically 
  500. able to receive calls directly from and exchange documents with other Teletex 
  501. devices. 
  502. .PP
  503. 3.2.4
  504. CCTs may technically use the Teletex protocol and terminal
  505. characteristics as prescribed in \(sc\ 3.3 of this Recommendation to exchange
  506. Teletex documents with each other.
  507. .PP
  508. 3.2.5
  509. If a Teletex device communicates with a CCT, it must be made aware of that 
  510. fact. How this information is conveyed within the Teletex terminal 
  511. identification with a specific value for Part\ 3 is described in \(sc\ 3.4.
  512. .sp 2P
  513. .LP
  514. 3.3
  515.     \fIApplicability of the relevant CCITT Recommendations\fR 
  516. .sp 1P
  517. .RT
  518. .sp 1P
  519. .LP
  520. 3.3.1
  521.     \fIProtocols\fR 
  522. .sp 9p
  523. .RT
  524. .LP
  525.     a)
  526.     The network capabilities are in accordance with \(sc 3 of
  527. Recommendation\ T.70.
  528. .LP
  529.     b)
  530.     The transport procedure is in accordance with either:
  531. .LP
  532.     \(em
  533.      Class 0 of the OSI transport protocol, as specified in Recommendations\ 
  534. X.214/X.224, together with application rules to be compatible with and 
  535. conform to the \(sc\ 5 and Annexes of Recommendation\ T.70; or 
  536. .LP
  537.     \(em
  538.     Paragraph 5 and annexes of Recommendation T.70.
  539. .LP
  540.     c)
  541.     The session layer procedure is in accordance with either:
  542. .LP
  543.     \(em
  544.     Kernel with the functional units minor sync,
  545. half\(hyduplex, capability data, activity management, and exceptions specified 
  546. in Recommendations\ X.215/X.225 together with application rules to be compatible 
  547. with and conform to Recommendation\ T.62; or
  548. .LP
  549.     \(em
  550.     Recommendation T.62.
  551. .LP
  552.     d)
  553.      The applicability of higher\(hylayer Recommendations, such as T.300 and 
  554. T.400, requires further study. 
  555. .sp 1P
  556. .LP
  557. 3.3.2
  558.     \fITerminal requirements and character repertoire\fR 
  559. .sp 9p
  560. .RT
  561. .PP
  562. The terminal requirements and character repertoire specified in
  563. Recommendations\ T.60 and\ T.61 will apply except for the following:
  564. .RT
  565. .LP
  566.     a)
  567.     A CCT may or may not support full automatic operation.
  568. .LP
  569.     b)
  570.     A CCT must be able to receive and store all characters
  571. belonging to the basic Teletex character repertoire. However, only those
  572. graphic characters which form the primary character set of the basic Teletex
  573. character set as defined in Recommendation\ T.61 need to be presented.
  574. .bp
  575. .LP
  576.     c)
  577.      A CCT may require a different terminal identification from that of a 
  578. Teletex terminal. The format of this identification is defined in 
  579. \(sc\ 3.4.3.1.
  580. .LP
  581.     d)
  582.     Other items require further study.
  583. .sp 2P
  584. .LP
  585. 3.4
  586.     \fIAccess methods\fR 
  587. .sp 1P
  588. .RT
  589. .sp 1P
  590. .LP
  591. 3.4.1
  592.     \fIIntroduction\fR 
  593. .sp 9p
  594. .RT
  595. .PP
  596. This paragraph describes a technical method for CCT access to and from 
  597. the Teletex service. This access method is based on the assumption that 
  598. CCTs should enjoy a maximum flexibility and that the service characteristics 
  599. of Teletex should not be degraded. 
  600. .PP
  601. These prerequisites imply that the CCT must be supported by a service access 
  602. facility (SAF) which emulates the Teletex service characteristics and 
  603. provide for the handling of messages.
  604. .RT
  605. .sp 1P
  606. .LP
  607. 3.4.2
  608.     \fIDescription of the access method\fR 
  609. .sp 9p
  610. .RT
  611. .PP
  612. A CCT may establish a connection to the SAF at any time, from any network 
  613. and from any access point within these networks. If a CCT wants to 
  614. transmit a message but does not wish to receive a message, it need not be
  615. identified. The message will be received by the SAF and forwarded immediately 
  616. to the Teletex destination. The SAF must add information which will indicate 
  617. to the Teletex destination that this message was originated by an unidentified 
  618. CCT.
  619. .PP
  620. If a CCT is to receive an answer to its previously transmitted
  621. message, it should be able to register itself temporarily using a password. 
  622. The password will be provided by the CCT user. The message from the CCT 
  623. will be 
  624. forwarded immediately to the Teletex destination including information 
  625. that the answer may be placed in the SAF under the given password. Provisions 
  626. to allow positive or negative acknowledgements to the Teletex source and 
  627. to allow 
  628. control of the status of messages sent by the Teletex source are technically
  629. feasible.
  630. .PP
  631. In the following, the functions of the SAF are described which are
  632. needed to support CCTs for access to/from the Teletex service.
  633. .RT
  634. .sp 1P
  635. .LP
  636. 3.4.3
  637.     \fIModel\fR (see Figure 3/T.65)
  638. .sp 9p
  639. .RT
  640. .LP
  641. .rs
  642. .sp 11P
  643. .ad r
  644. \fBFigure 3/T.65, p.\fR 
  645. .sp 1P
  646. .RT
  647. .ad b
  648. .RT
  649. .sp 1P
  650. .LP
  651. 3.4.3.1
  652.     \fICCT to Teletex\fR 
  653. .sp 9p
  654. .RT
  655. .PP
  656. The following functions will be provided by the SAF in order to
  657. enable a CCT to access the Teletex service:
  658. .RT
  659. .LP
  660.     a)
  661.     insertion of an appropriate information from which the
  662. Teletex subscribes can identify that the message is being sent from a CCT
  663. (e.g.,\ the letters \*QCCT\*U into Part\ 3 of the Teletex\(hyTID);
  664. .LP
  665.     b)
  666.     temporary registration on an optional basis (to allow
  667. messages to be sent back to the CCT by a Teletex terminal, see
  668. \(sc\ 3.4.3.2).
  669. .bp
  670. .sp 1P
  671. .LP
  672. 3.4.3.2
  673.     \fITeletex to CCT\fR 
  674. .sp 9p
  675. .RT
  676. .PP
  677. The following functions will be provided by the SAF in order to
  678. enable a Teletex terminal to send documents to a CCT:
  679. .RT
  680. .LP
  681.     a)
  682.     memory for storing messages sent by the Teletex terminal;
  683. .LP
  684.     b)
  685.     allocation of stored messages to registration numbers to
  686. allow their retrieval by the CCT;
  687. .LP
  688.     c)
  689.     means for a delivery notification call to the Teletex
  690. terminal to indicate that the CCT has retrieved the message;
  691. .LP
  692.     d)
  693.      a time\(hyout mechanism for deleting a message if not retrieved within 
  694. a certain period of time; 
  695. .LP
  696.     e)
  697.     additional notification calls (e.g., status of stored
  698. messages) are for further study.
  699. .sp 2P
  700. .LP
  701. \fB4\fR     \fBAccess to the Group 3 facsimile service\fR 
  702. .sp 1P
  703. .RT
  704. .sp 1P
  705. .LP
  706. 4.1
  707.     \fIGeneral\fR 
  708. .sp 9p
  709. .RT
  710. .PP
  711. A CCT may be used to access the Group 3 facsimile service.
  712. .RT
  713. .sp 1P
  714. .LP
  715. 4.2
  716.     \fICharacteristics\fR 
  717. .sp 9p
  718. .RT
  719. .PP
  720. A CCT accessing the Group 3 facsimile service will operate in
  721. accordance with the CCITT Recommendations\ T.4 and\ T.30.
  722. .RT
  723. .sp 2P
  724. .LP
  725. 4.3
  726.     \fIApplicability of the relevant CCITT Recommendations\fR 
  727. .sp 1P
  728. .RT
  729. .sp 1P
  730. .LP
  731. 4.3.1
  732.     \fIProtocols\fR 
  733. .sp 9p
  734. .RT
  735. .PP
  736. The requirements defined in the CCITT Recommendation T.30
  737. apply.
  738. .RT
  739. .sp 1P
  740. .LP
  741. 4.3.2
  742.     \fIModulation systems\fR 
  743. .sp 9p
  744. .RT
  745. .PP
  746. The requirements defined in the CCITT Recommendation T.4
  747. apply.
  748. .RT
  749. .sp 2P
  750. .LP
  751. \fB5\fR     \fBAccess to the Group 4 facsimile service\fR 
  752. .sp 1P
  753. .RT
  754. .PP
  755. (For further study.)
  756. .RT
  757. .sp 2P
  758. .LP
  759. \fB6\fR     \fBAccess to the mixed\(hymode option of the Teletex service\fR 
  760. .sp 1P
  761. .RT
  762. .PP
  763. (For further study.)
  764. .RT
  765. .sp 2P
  766. .LP
  767. \fB7\fR     \fBAccess to the videotex service\fR 
  768. .sp 1P
  769. .RT
  770. .sp 1P
  771. .LP
  772. 7.1
  773.     \fIGeneral\fR 
  774. .sp 9p
  775. .RT
  776. .PP
  777. A CCT may be used to access the videotex service. Since a videotex service 
  778. will not distinguish between what type of terminal is connected to it, 
  779. there are no special requirements for CCTs above those which apply to dedicated 
  780. videotex terminals. 
  781. .RT
  782. .sp 1P
  783. .LP
  784. 7.2
  785.     \fICharacteristics\fR 
  786. .sp 9p
  787. .RT
  788. .PP
  789. 7.2.1
  790. CCTs accessing the videotex service should emulate videotex
  791. terminal characteristics. In the emulation, attention should be given to the
  792. profiles, ranks or service reference modes of the videotex terminals concerned 
  793. as used in the various videotex services. Where insufficient display 
  794. capabilities are available, a CCT should provide fall\(hyback by graceful
  795. degradation of capabilities so that the integrity of the information content 
  796. is preserved. For example, a wide range of colours may fall back to fewer 
  797. related colours, or to grey scales, or an accented character may fall back 
  798. to a 
  799. character without accent.
  800. .sp 9p
  801. .RT
  802. .PP
  803. 7.2.2
  804. Videotex services are interactive and CCTs should be able to
  805. transmit and receive data interactively.
  806. .bp
  807. .sp 2P
  808. .LP
  809. 7.3
  810.     \fIApplicability of the relevant CCITT Recommendations\fR 
  811. .sp 1P
  812. .RT
  813. .sp 1P
  814. .LP
  815. 7.3.1
  816.     \fIProtocols\fR 
  817. .sp 9p
  818. .RT
  819. .PP
  820. To be defined.
  821. .RT
  822. .sp 1P
  823. .LP
  824. 7.3.2
  825.     \fIData syntax and terminal requirements\fR 
  826. .sp 9p
  827. .RT
  828. .PP
  829. The requirements defined in CCITT Recommendation T.101 (Annexes B, C and 
  830. D) apply. 
  831. .RT
  832. .sp 2P
  833. .LP
  834. \fB8\fR     \fBAccess to MHS\fR 
  835. .sp 1P
  836. .RT
  837. .sp 1P
  838. .LP
  839. 8.1
  840.     \fIGeneral\fR 
  841. .sp 9p
  842. .RT
  843. .PP
  844. This paragraph describes the characteristics of CCTs to access MHS and 
  845. specifies how the various related Recommendations may be used. 
  846. .RT
  847. .sp 1P
  848. .LP
  849. 8.2
  850.     \fICharacteristics\fR 
  851. .sp 9p
  852. .RT
  853. .PP
  854. In its present form, the message handling system has as its
  855. fundamental component the message transfer system (MTS), which comprises a
  856. number of message transfer agents (MTAs). A CCT can then access MHS in 
  857. two ways as described in Figure\ 4/T.65 and the text below. 
  858. .RT
  859. .LP
  860. .rs
  861. .sp 7P
  862. .ad r
  863. \fBFigure 4/T.65, p.\fR 
  864. .sp 1P
  865. .RT
  866. .ad b
  867. .RT
  868. .LP
  869.     i)
  870.     The CCT can access MHS through a telematic interworking
  871. facility (TIF) as defined in Recommendations\ T.300\(hySeries.
  872. .LP
  873.     ii)
  874.     The CCT can support the MHS user agent functions to access  the MTS directly.
  875. .sp 1P
  876. .LP
  877. 8.3
  878.     \fIApplicability of the relevant CCITT Recommendations\fR 
  879. .sp 9p
  880. .RT
  881. .PP
  882. When a CCT does not support the MHS user agent functions it shall access 
  883. MHS through a TIF, which provides for interworking between Telematic 
  884. services and MHS. In this case the relevant sections of
  885. Recommendations\ T.300\(hySeries and\ T.65 apply, depending on the choice of
  886. protocols and terminal characteristics.
  887. .PP
  888. When a CCT supports the MHS user agent functions in addition to the
  889. Telematic protocols and terminal characteristics, it will use the relevant
  890. sections in the series of Recommendations\ X.400.
  891. .RT
  892. .sp 2P
  893. .LP
  894. \fB9\fR     \fBAccess to the directory service\fR 
  895. .sp 1P
  896. .RT
  897. .sp 1P
  898. .LP
  899. 9.1
  900.     \fIGeneral\fR 
  901. .sp 9p
  902. .RT
  903. .PP
  904. The access of CCTs to the directory service will often precede the other 
  905. CCITT\(hydefined services such as MHS, Teletex, or telephony, in order 
  906. to 
  907. determine or ascertain the address of a user or service. This section describes 
  908. the characteristics of such an access and specifies how the various related 
  909. Recommendations may be used.
  910. .bp
  911. .RT
  912. .sp 1P
  913. .LP
  914. 9.2
  915.     \fICharacteristics\fR 
  916. .sp 9p
  917. .RT
  918. .PP
  919. In its present form, the directory system has two fundamental
  920. components: the directory user agent (DUA) and the directory (see
  921. Figure\ 5/T.65).
  922. .RT
  923. .LP
  924. .rs
  925. .sp 10P
  926. .ad r
  927. \fBFigure 5/T.65, p.\fR 
  928. .sp 1P
  929. .RT
  930. .ad b
  931. .RT
  932. .PP
  933. In terms of this model two ways of CCT access are possible:
  934. .LP
  935.     i)
  936.     The CCT can access the DUA using suitable telematic
  937. protocols and terminal characteristics defined in the T\(hySeries of
  938. Recommendations.
  939. .LP
  940.     ii)
  941.     The CCT can support DUA functions to access the directory   directly.
  942. .PP
  943. It should be noted that directory access is essentially an
  944. interactive application. Therefore, this interactive nature influences the
  945. protocol and terminal requirements.
  946. .sp 1P
  947. .LP
  948. 9.3
  949.     \fIApplicability of the relevant CCITT Recommendations\fR 
  950. .sp 9p
  951. .RT
  952. .PP
  953. When a CCT does not support DUA functions, it shall access the
  954. directory through a DUA. In this case the relevant sections of the
  955. Recommendations\ X.500 and\ T.65 apply, depending on the choice of protocols 
  956. and terminal characteristics. 
  957. .PP
  958. When a CCT supports DUA functions in addition to the Telematic
  959. protocols and terminal characteristics it will use the relevant sections 
  960. in the series of Recommendations\ X.500. 
  961. \v'1P'
  962. .RT
  963. .sp 2P
  964. .LP
  965. \fBRecommendation\ T.70\fR 
  966. .RT
  967. .sp 2P
  968. .sp 1P
  969. .ce 1000
  970. \fBNETWORK\(hyINDEPENDENT\ BASIC\ TRANSPORT\ SERVICE\fR  |
  971. \fBFOR\ THE\ TELEMATIC\ SERVICES\fR 
  972. .EF '%    Fascicle\ VII.5\ \(em\ Rec.\ T.70''
  973. .OF '''Fascicle\ VII.5\ \(em\ Rec.\ T.70    %'
  974. .ce 0
  975. .sp 1P
  976. .ce 1000
  977. \fI(Geneva, 1980, amended at Malaga\(hyTorremolinos, 1984,\fR 
  978. .sp 9p
  979. .RT
  980. .ce 0
  981. .sp 1P
  982. .ce 1000
  983. \fIand Melbourne, 1988)\fR 
  984. .ce 0
  985. .sp 1P
  986. .LP
  987.     The\ CCITT,
  988. .sp 1P
  989. .RT
  990. .sp 1P
  991. .LP
  992. \fIconsidering\fR 
  993. .sp 9p
  994. .RT
  995. .PP
  996. (a)
  997. that the Teletex service will be introduced in different types of network, 
  998. i.e.\ circuit\(hyswitched public data networks (CSPDN), 
  999. packet\(hyswitched public data networks (PSPDN) and the public switched
  1000. telephone network\ (PSTN);
  1001. .PP
  1002. (b)
  1003. that there is a need for international 
  1004. interworking  \ between terminals
  1005. belonging to the same or different types of
  1006. Telematic services
  1007. ;
  1008. .bp
  1009. .LP
  1010. \fIunanimously declares the following view\fR 
  1011. .sp 1P
  1012. .RT
  1013. .sp 2P
  1014. .LP
  1015. \fB1\fR     \fBScope\fR 
  1016. .sp 1P
  1017. .RT
  1018. .PP
  1019. 1.1
  1020. This Recommendation defines the \fInetwork\(hyindependent basic\fR 
  1021. \fItransport service\fR applicable to Teletex and Group\ 4 facsimile terminals
  1022. connected to the types of network mentioned in\ (a) above in terms of:
  1023. .sp 9p
  1024. .RT
  1025. .LP
  1026.     a)
  1027.     the transport services provided to the higher layer [the
  1028. transport services are provided by the transport layer (layer\ 4)
  1029. in association with the underlying services provided by the
  1030. supporting layers\ 1 to\ 3];
  1031. .LP
  1032.     b)
  1033.     the transport layer procedure (see \(sc\ 5 below).
  1034. .PP
  1035. 1.2
  1036. Paragraph 2 describes the transport service. Paragraph\ 3
  1037. describes the transport service implementation for different types of networks. 
  1038. Paragraph\ 4 outlines the guidelines for interworking between networks. 
  1039. Paragraph\ 5 specifies the transport layer procedure, and Annexes\ A and\ B
  1040. provide associated state transition diagrams and tables respectively.
  1041. .LP
  1042. \fB2\fR     \fBTransport service\fR 
  1043. .sp 1P
  1044. .RT
  1045. .sp 2P
  1046. .LP
  1047. 2.1
  1048.     \fITransport service objectives\fR 
  1049. .sp 1P
  1050. .RT
  1051. .PP
  1052. 2.1.1
  1053. The purpose of the transport service is to provide two
  1054. communicating session entities within two terminals with transport services,
  1055. i.e.\ the means for transparent and reliable end\(hyto\(hyend transfer 
  1056. of data between them irrespective of the particular type of network used. 
  1057. .sp 9p
  1058. .RT
  1059. .PP
  1060. 2.1.2
  1061. The main requirements of the transport service to be provided
  1062. by a transport entity to the local transport user, i.e.\ the session entity,
  1063. are:
  1064. .LP
  1065.     a)
  1066.     \fINetwork independence\fR . The transport service shall be
  1067. homogeneous, while allowing a suitable wide variety of
  1068. underlying communications media, protocols and mechanisms.
  1069. .LP
  1070.     b)
  1071.     \fIEnd\(hyto\(hyend significance\fR . The transport service shall have
  1072. end\(hyto\(hyend significance, connecting the end users irrespective
  1073. of the number of individual communication links used.
  1074. .LP
  1075.     c)
  1076.     \fITransparency\fR . The transport service shall be octet
  1077. transparent, i.e.\ not restrict the content, format or coding of
  1078. the information (data or control) received from or delivered to
  1079. the transport user.
  1080. .LP
  1081.     d)
  1082.     \fIError\(hyfree delivery\fR . The transport service shall assure
  1083. error\(hyfree delivery. Non\(hyrecoverable errors are to be visible to
  1084. the transport service user.
  1085. .LP
  1086.     e)
  1087.     \fICost efficiency\fR . The transport service shall optimize the
  1088. use of the available communication resources to provide the
  1089. performance required by each communicating transport user at
  1090. maximum efficiency.
  1091. .sp 2P
  1092. .LP
  1093. 2.2
  1094.     \fIGeneral structure of the transport service\fR 
  1095. .sp 1P
  1096. .RT
  1097. .PP
  1098. 2.2.1
  1099. The general structure of the transport service is shown in
  1100. Figure\ 1/T.70.
  1101. .sp 9p
  1102. .RT
  1103. .sp 2P
  1104. .LP
  1105. \fB3\fR     \fBTransport service implementation for different types of\fR 
  1106. \fBnetworks\fR 
  1107. .sp 1P
  1108. .RT
  1109. .PP
  1110. \fINote\fR \ \(em\ The 
  1111. transport layer
  1112. procedure on all types of
  1113. networks is defined in \(sc\ 5. The network dependent control procedures of the
  1114. underlying layers are described in the following.
  1115. .RT
  1116. .sp 2P
  1117. .LP
  1118. 3.1
  1119.     \fITerminals connected to a PSPDN\fR 
  1120. .sp 1P
  1121. .RT
  1122. .sp 1P
  1123. .LP
  1124. 3.1.1
  1125.     \fIPhysical layer\fR \fIDTE/DCE interface characteristics\fR 
  1126. .sp 9p
  1127. .RT
  1128. .PP
  1129. The physical layer of Recommendation\ X.25 applies.
  1130. .RT
  1131. .sp 1P
  1132. .LP
  1133. 3.1.2
  1134.     \fILink layer procedure\fR 
  1135. .sp 9p
  1136. .RT
  1137. .PP
  1138. The 
  1139. link layer
  1140. procedure shall, unless otherwise specified, be the symmetrical procedures 
  1141. as specified in Recommendation\ X.25, LAPB (Link Access Procedure\ B). 
  1142. .bp
  1143. .RT
  1144. .LP
  1145. .rs
  1146. .sp 47P
  1147. .ad r
  1148. \fBFigure 1/T.70 TO803680\(hy89, p.6\fR 
  1149. .sp 1P
  1150. .RT
  1151. .ad b
  1152. .RT
  1153. .LP
  1154. .bp
  1155. .sp 1P
  1156. .LP
  1157. 3.1.3
  1158.     \fINetwork layer procedure\fR 
  1159. .sp 9p
  1160. .RT
  1161. .PP
  1162. Recommendation X.25 Virtual Call procedures apply. However the
  1163. following points should be noted when using this 
  1164. transport
  1165. protocol
  1166. :
  1167. .RT
  1168. .LP
  1169.     a)
  1170.     The 
  1171. qualifier bit
  1172. in data packets should always be   set to 0.
  1173. .LP
  1174.     b)
  1175.     The 
  1176. delivery confirmation bits
  1177. in all packets should
  1178. be set to\ 0.
  1179. .LP
  1180.     c)
  1181.     The terminal should not send an \fIinterrupt request\fR packet.
  1182. .LP
  1183.     d)
  1184.     Normal X.25 reset procedures will apply.
  1185. .LP
  1186.     e)
  1187.     Each control block or data block of the 
  1188. transport
  1189. layer
  1190. shall be carried in a complete data packet sequence.
  1191. .LP
  1192.     f
  1193. )
  1194.     The terminal should not send a \fIDTE\ REJ packet\fR .
  1195. .LP
  1196.     g)
  1197.     Terminals shall use a specific 
  1198. protocol identifier
  1199. within
  1200. call request/incoming call packets for the Teletex service and
  1201. Group\ 4 facsimile apparatus. This identifier is represented
  1202. by the first octet of the call user data field (remaining
  1203. octets, if any, should be ignored) as shown below:
  1204. .LP
  1205.     bit
  1206.     87654321
  1207. .LP
  1208.     octet\ 1
  1209.     00000010
  1210. .LP
  1211.     In the case of CSPDN/PSPDN interworking the functional
  1212. mapping of this protocol identifier requires further study.
  1213. .LP
  1214.     h)
  1215.     Terminals shall not use the fast select facility.
  1216. .sp 2P
  1217. .LP
  1218. 3.2
  1219.     \fITerminals connected to the PSTN\fR 
  1220. .sp 1P
  1221. .RT
  1222. .sp 1P
  1223. .LP
  1224. 3.2.1
  1225.     \fIPhysical layer DTE/DCE interface characteristics\fR 
  1226. .sp 9p
  1227. .RT
  1228. .PP
  1229. The DTE/DCE physical layer element shall be in accordance with
  1230. existing Series\ V Recommendations. The physical layer may provide for
  1231. half\(hyduplex or full\(hyduplex transmission depending on the modem standard.
  1232. .PP
  1233. \fINote\fR \ \(em\ The PSTN modem standards are discussed in Study Group\ 
  1234. XVII. Furthermore, in the case of a modem integrated in the terminal, the 
  1235. interface may only be functionally equivalent to a Series\ V Recommendation. 
  1236. This is also for further consideration in Study Group\ XVII. 
  1237. .RT
  1238. .sp 2P
  1239. .LP
  1240. 3.2.2
  1241.     \fILink layer procedure\fR 
  1242. .sp 1P
  1243. .RT
  1244. .PP
  1245. 3.2.2.1
  1246. Depending on the service provided by the physical layer, the
  1247. link layer procedures over a single physical circuit between two terminals 
  1248. have to cater for a half\(hyduplex or full\(hyduplex transmission facility 
  1249. to provide a 
  1250. full\(hyduplex service to the network layer. For full\(hyduplex physical layer
  1251. service, the link layer procedure shall conform to the 
  1252. Link Access
  1253. Procedure
  1254. described in Recommendation\ X.75, for single link operation. For addressing
  1255. assignments and the system parameters see \(sc\(sc\ 3.2.2.2 and\ 3.2.2.3 
  1256. respectively. For half\(hyduplex physical layer service the link layer 
  1257. procedure is as defined in Recommendation\ T.71. This is a half\(hyduplex 
  1258. Link Access Procedure
  1259. ,
  1260. based on Recommendation\ X.75 for single link operation.
  1261. .sp 9p
  1262. .RT
  1263. .PP
  1264. 3.2.2.2
  1265. The following describes the application of the 
  1266. link
  1267. addressing
  1268. procedure
  1269. of Recommendation\ X.75. Link addresses (A\ and\ B) shall be
  1270. assigned dynamically or on a per\(hycall basis according to the following
  1271. rules:
  1272. .LP
  1273.     a)
  1274.     the calling terminal shall take Address\ A;
  1275. .LP
  1276.     b)
  1277.     the called terminal shall take Address\ B;
  1278. .LP
  1279.     c)
  1280.     commands and responses shall be transferred as shown in
  1281. Figure\ 2/T.70;
  1282. .LP
  1283.     d)
  1284.     A and B addresses are coded as follows:
  1285. .LP
  1286.     Address
  1287.     12345678
  1288. .LP
  1289.     \ \ A
  1290.     11000000
  1291. .LP
  1292.     \ \ B
  1293.     10000000
  1294. .PP
  1295. \fINote\fR \ \(em\ The terminal will discard all frames received with an
  1296. address other than\ A and\ B.
  1297. .bp
  1298. .LP
  1299. .rs
  1300. .sp 9P
  1301. .ad r
  1302. \fBFigure 2/T.70 p.\fR 
  1303. .sp 1P
  1304. .RT
  1305. .ad b
  1306. .RT
  1307. .PP
  1308. 3.2.2.3
  1309. System parameters are:
  1310. .LP
  1311.     a)
  1312.     timer, T1;
  1313. .LP
  1314.     b)
  1315.     maximum number of retransmissions, N2;
  1316. .LP
  1317.     c)
  1318.     maximum number of bits in an I frame, N1;
  1319. .LP
  1320.     d)
  1321.     maximum number of outstanding I frames, \fIk\fR .
  1322. .PP
  1323. The above system parameters are to be specified by the
  1324. Administration.
  1325. However, the possible range of values that may be attributed to each parameter 
  1326. is to be standardized. Such values are for further study. 
  1327. .sp 2P
  1328. .LP
  1329. 3.2.3
  1330.     \fINetwork layer procedure\fR 
  1331. .sp 1P
  1332. .RT
  1333. .PP
  1334. 3.2.3.1
  1335. See \(sc\ 3.1.3. In addition, for all calls (PSTN only, PSTN\(hyPSPDN, 
  1336. PSTN\(hyPSPDN\(hyPSTN) 
  1337. second stage addressing
  1338. will apply using X.25 virtual call procedures. The calling terminal should 
  1339. include the called address and the calling address (see Note\ 2) in call 
  1340. request packets. The format of the called address shall conform to: 
  1341. .sp 9p
  1342. .RT
  1343. .LP
  1344.     a)
  1345.     the telephone network addressing scheme for PSTN only
  1346. calls;
  1347. .LP
  1348.     b)
  1349.     the telephone network addressing scheme with an X.121 DNIC
  1350. for PSTN\(hyPSPDN calls (see Note\ 3);
  1351. .LP
  1352.     c)
  1353.     the X.121 addressing scheme for PSTN\(hyPSPDN calls (see
  1354. Note\ 1).
  1355. .PP
  1356. \fINote\ 1\fR \ \(em\ For other cases of internetworking the above rule 
  1357. shall apply. 
  1358. .PP
  1359. \fINote\ 2\fR \ \(em\ In the case of PSTN\(hyPSPDN calls the verification 
  1360. of the 
  1361. calling address by the network requires further study. The format of the
  1362. calling address is for further study.
  1363. .PP
  1364. \fINote\ 3\fR \ \(em\ The feasibility of such connections is for further
  1365. study.
  1366. .RT
  1367. .sp 2P
  1368. .LP
  1369. 3.3
  1370.     \fITerminals connected to a CSPDN\fR 
  1371. .sp 1P
  1372. .RT
  1373. .sp 1P
  1374. .LP
  1375. 3.3.1
  1376.     \fIPhysical layer DTE/DCE interface characteristics\fR 
  1377. .sp 9p
  1378. .RT
  1379. .PP
  1380. The DTE/DCE physical interface characteristics shall be in
  1381. accordance with Recommendation\ X.21, or as an option, Recommendation\ 
  1382. X.22 for multi\(hycall operation. 
  1383. .RT
  1384. .sp 2P
  1385. .LP
  1386. 3.3.2
  1387.     \fILink layer procedure\fR 
  1388. .sp 1P
  1389. .RT
  1390. .sp 1P
  1391. .LP
  1392. 3.3.2.1
  1393.     \fIGeneral\fR 
  1394. .sp 9p
  1395. .RT
  1396. .PP
  1397. The link layer procedure shall be used during the data phase of
  1398. Recommendation\ X.21 (or\ X.22) for data interchange over a single physical
  1399. circuit between two terminals operating in User Classes of Services\ 3 to\ 7
  1400. and\ 30 as defined in Recommendation\ X.1. The link layer procedure shall 
  1401. consist of a fully symmetrical HDLC procedure as defined in Recommendation\ 
  1402. X.75 for 
  1403. single link operation.
  1404. .bp
  1405. .RT
  1406. .sp 1P
  1407. .LP
  1408. 3.3.2.2
  1409.     \fILink layer address procedure\fR 
  1410. .sp 9p
  1411. .RT
  1412. .PP
  1413. The following describes the application of the link addressing
  1414. procedures of Recommendation\ X.75. Link addresses (A\ and\ B) shall be 
  1415. assigned dynamically on a per\(hycall basis according to the following 
  1416. rules: 
  1417. .RT
  1418. .LP
  1419.     a)
  1420.     the calling terminal shall take address\ A;
  1421. .LP
  1422.     b)
  1423.     the called terminal shall take address\ B;
  1424. .LP
  1425.     c)
  1426.     commands and responses shall be transferred as shown in
  1427. Figure\ 3/T.70;
  1428. .LP
  1429.     d)
  1430.     A and B addresses are coded as follows:
  1431. .LP
  1432.     Address
  1433.     12345678
  1434. .LP
  1435.     \ \ A
  1436.     11000000
  1437. .LP
  1438.     \ \ B
  1439.     10000000
  1440. .PP
  1441. \fINote\fR \ \(em\ The terminal will discard all frames received with an
  1442. address other than\ A and\ B.
  1443. .LP
  1444. .rs
  1445. .sp 9P
  1446. .ad r
  1447. \fBFigure 3/T.70, p.\fR 
  1448. .sp 1P
  1449. .RT
  1450. .ad b
  1451. .RT
  1452. .sp 1P
  1453. .LP
  1454. 3.3.2.3
  1455.     \fILink layer implementation rules\fR 
  1456. .sp 9p
  1457. .RT
  1458. .PP
  1459. In order to achieve full compatibility between different
  1460. implementations, the rules below for the implementation of Recommendation\ 
  1461. X.75 shall be followed. 
  1462. .RT
  1463. .sp 1P
  1464. .LP
  1465. 3.3.2.3.1
  1466.     \fIGeneral rules\fR 
  1467. .sp 9p
  1468. .RT
  1469. .LP
  1470.     a)
  1471.      The 1984 version (\fIRed Book\fR ) of CCITT Recommendation\ X.75, \(sc\ 
  1472. 2, shall be used as the reference specification. 
  1473. .LP
  1474.     b)
  1475.     The term \*QSTE\*U shall be read as \*QDTE\*U.
  1476. .LP
  1477.     c)
  1478.     The Non\(hyExtended mode of operation (modulo 8) shall be
  1479. used.
  1480. .LP
  1481.     d)
  1482.     Only the single link procedure (SLP) shall be used.
  1483. .sp 1P
  1484. .LP
  1485. 3.3.2.3.2
  1486.     \fISpecific rules\fR 
  1487. .sp 9p
  1488. .RT
  1489. .PP
  1490. The following rules refer to the indicated sections and tables of Recommendation\ 
  1491. X.75. 
  1492. .RT
  1493. .LP
  1494.     a)
  1495.     \fITable 1/X.75\fR (see Note 1)
  1496. .LP
  1497.     I\(hyframe must not be sent with an empty I\(hyfield.
  1498. .LP
  1499. N\ \(>="\ 0
  1500. .LP
  1501. N\ \(=\ N1 \(em 32
  1502. .LP
  1503. A received empty I\(hyframe shall be treated as a valid
  1504. I\(hyframe.
  1505. .LP
  1506.     b)
  1507.     \fI\(sc 2.3.4.9\fR 
  1508. .LP
  1509.      Subparagraphs 5), 6) and 7) are not valid (shall not result in the sending 
  1510. of a FRMR). Instead the following actions shall be implemented: 
  1511. .LP
  1512.     \(em
  1513.     Not expected supervisory frames with the F bit set to 1 shall be ignored.
  1514. .LP
  1515.     \(em
  1516.     Not expected UA or DM response shall be ignored.
  1517. .LP
  1518.     \(em
  1519.     Frames with an invalid N(S) shall be responded to by sending  REJECT.
  1520. .LP
  1521.     Frames with a FRMR cntrol field shall not be responded by sending  a FRMR.
  1522. .bp
  1523. .LP
  1524.     c)
  1525.     \fITable 7/X.75\fR 
  1526. .LP
  1527.     Bits W, X, Y and Z set to 0 indicate that no reason for
  1528. frame rejection is given.
  1529. .LP
  1530.     d)
  1531.     \fI\(sc 2.3.5.3\fR 
  1532. .LP
  1533.     The DTE and the CSPDN are not octet aligned and the last
  1534. paragraph is therefore not valid.
  1535. .LP
  1536.     e)
  1537.     \fI\(sc 2.3.5.5\fR 
  1538. .LP
  1539.     Higher layers should be notified when timer T3 expires
  1540. (excessive idle state).
  1541. .LP
  1542.     f
  1543. )
  1544.     \fI\(sc 2.4.3\fR 
  1545. .LP
  1546.     Related to the first paragraph, read instead of \*Qnext
  1547. response\*U \*Qcorresponding response\*U.
  1548. .LP
  1549.     g)
  1550.     \fI\(sc 2.4.4.1\fR 
  1551. .LP
  1552.     In the active channel state, the DTE shall transmit
  1553. contiguous flags independent of the other DTE.
  1554. .LP
  1555.      The calling DTE shall initialize the link by sending a SABM command with 
  1556. the P\ bit set to\ 1. 
  1557. .LP
  1558.     h)
  1559.     \fI\(sc 2.4.4.4.1\fR 
  1560. .LP
  1561.      A condition for entering the disconnected phase is also that no unacknowledged 
  1562. DISC command exists, because of collision cases (Ref.\ X.75, \(sc\ 2.4.4.5). 
  1563. .LP
  1564.      In the disconnected phase, it is the calling DTE which may initiate link 
  1565. set up. 
  1566. .LP
  1567.     i)
  1568.     \fI\(sc 2.4.5.9, fourth paragraph\fR 
  1569. .LP
  1570.     If a RNR is received, the DTE shall remain in the timer
  1571. recovery condition (because the other DTE is still in the busy condition).
  1572. .LP
  1573.     j)
  1574.     \fI\(sc 2.4.5.9, fifth paragraph\fR 
  1575. .LP
  1576.     If a RNR is received, the DTE shall not resume I\(hyframe
  1577. transmission or retransmission.
  1578. .LP
  1579.     k)
  1580.     \fI\(sc 2.4.5.9, last paragraph\fR 
  1581. .LP
  1582.      If the transmission attempt variable is equal to N2, the DTE shall enter 
  1583. the disconnected phase. 
  1584. .LP
  1585.     l)
  1586.     \fI\(sc 2.4.7.3\fR 
  1587. .LP
  1588.      In the frame rejection condition, the DTE shall only check the commands 
  1589. and react with a FRMR according to the P\ bit. 
  1590. .LP
  1591.     The frame rejection condition is cleared when the DTE
  1592. receives a SABM, or, receives or transmits a DISC command.
  1593. .LP
  1594.     m)
  1595.     \fI\(sc 2.4.7.3, second paragraph\fR (see Note 2)
  1596. .LP
  1597.     Only the DTE which caused the FRMR condition may try to
  1598. reset the link.
  1599. .LP
  1600.     n)
  1601.     \fI\(sc 2.4.7.3, third paragraph\fR (see Note 3)
  1602. .LP
  1603.     After N2 attempts to get the other DTE to reset the link,
  1604. the DTE shall enter the disconnected phase.
  1605. .LP
  1606.     o)
  1607.     \fI\(sc 2.4.8.1\fR (see Note 4)
  1608. .LP
  1609.     The timer T1 shall be started at the end of frame
  1610. transmission. The value of T1 depends on the data signalling rate, the frame
  1611. length, the value of N2 and a fixed time of 1.5\ s representing both T2 
  1612. and the transmission delay [see \(sc\ 3.3.2.3.2 | )]. The recommended value 
  1613. range is: 
  1614. 1.5\(hy15\ s.
  1615. .LP
  1616.     p)
  1617.     \fI\(sc 2.4.8.2\fR (see Note 4)
  1618. .LP
  1619.     T1\ >\ T2
  1620. .LP
  1621.     T2\ \(=\ 1\ s
  1622. .LP
  1623.     Depending on the acknowledgement strategy used, the DTE
  1624. designer may regard T2 as a decision parameter only, in which case the 
  1625. DTE is not obliged to implement a corresponding timer. 
  1626. .LP
  1627.     q)
  1628.     \fI\(sc 2.4.8.3, second paragraph\fR 
  1629. .LP
  1630.     30\ s\ \(=\ T3\ \(=\ 60\ s
  1631. .LP
  1632.     r)
  1633.     \fI\(sc 2.4.8.4\fR 
  1634. .LP
  1635.     N2\ \(mu\ T1\ \(>="\ 60\ s
  1636. .LP
  1637.     s)
  1638.     \fI\(sc 2.4.8.5\fR 
  1639. .LP
  1640.     N1 = 1080 + (\fIn\fR \(mu 1024) bits; \fIn\fR = 0 or 1 or 3 or 7 or
  1641. 15.
  1642. .LP
  1643.     t)
  1644.     \fI\(sc 2.4.8.6\fR (see Note 4)
  1645. .LP
  1646.     \fIk\fR = 2 \(em 7 (modulo 8)
  1647. .bp
  1648. .LP
  1649.     \fINote\ 1\fR \ \(em\ Terminals complying with the \fIRed Book\fR version of
  1650. Recommendation\ T.70 may react by DL Reset ind. (FRMR).
  1651. .LP
  1652.     \fINote\ 2\fR \ \(em\ Terminals complying with the \fIRed Book\fR version of
  1653. Recommendation\ T.70 may react differently.
  1654. .LP
  1655.      \fINote\ 3\fR \ \(em\ It is not meaningful to reset the link if the other 
  1656. DTE is not responding for N2\ \(mu\ T1. 
  1657. .LP
  1658.      \fINote\ 4\fR \ \(em\ The acknowledgement strategy used by the receiving 
  1659. DTE should be independent of any knowledge about the value of \fIk\fR used 
  1660. by the 
  1661. sending
  1662. DTE. This can be achieved by either acknowledging every correctly received
  1663. I\(hyframe as soon as possible or by implementing an acknowledgement timer,
  1664. i.e.,\ a T2 timer as defined above [see \(sc\ 3.3.2.3.2 | )].
  1665. .sp 2P
  1666. .LP
  1667. 3.3.3
  1668.     \fINetwork layer procedure\fR 
  1669. .sp 1P
  1670. .RT
  1671. .sp 1P
  1672. .LP
  1673. 3.3.3.1
  1674.     \fICall control phase\fR 
  1675. .sp 9p
  1676. .RT
  1677. .PP
  1678. The call control procedure conforms to Recommendation\ X.21, or as an option, 
  1679. Recommendation\ X.22 for multi\(hycall operation. 
  1680. .RT
  1681. .sp 1P
  1682. .LP
  1683. 3.3.3.2
  1684.     \fIData transfer phase\fR 
  1685. .sp 9p
  1686. .RT
  1687. .PP
  1688. A minimal network layer is present during the data transfer phase and accommodated 
  1689. through the use of a two\(hyoctet network block header. The 
  1690. header comprises a one\(hyoctet length indicator followed by a network 
  1691. block type code specified below. The only network block currently defined 
  1692. is a 
  1693. network protocol data block
  1694. as shown in Figure\ 4/T.70.
  1695. .RT
  1696. .LP
  1697. .rs
  1698. .sp 22P
  1699. .ad r
  1700. \fBFigure 4/T.70, p.\fR 
  1701. .sp 1P
  1702. .RT
  1703. .ad b
  1704. .RT
  1705. .sp 2P
  1706. .LP
  1707. 3.3.3.3
  1708.     \fIData transfer procedure\fR 
  1709. .sp 1P
  1710. .RT
  1711. .sp 1P
  1712. .LP
  1713. 3.3.3.3.1
  1714.     \fIHandling of the\fR 
  1715. \fIM\(hybit\fR 
  1716. .sp 9p
  1717. .RT
  1718. .PP
  1719. The calling DTE shall negotiate the TPDU size with the called DTE at the 
  1720. transport layer, based on either the maximum TPDU size supported or the 
  1721. optimum TPDU size for the specific call, unless the default value of 128 
  1722. octets is used. The agreed value will allow the sending DTE to transfer 
  1723. TPDUs without the need for segmenting at the Network layer and consequently 
  1724. the M\(hybit is set to zero. 
  1725. .bp
  1726. .PP
  1727. However, receiving DTEs must always be capable of reassembling
  1728. segmented TPDUs by using the M\(hybit, since segmenting may take place in the
  1729. network in some interworking situations, e.g.,\ when the composite network
  1730. connection comprises a PSDN.
  1731. .RT
  1732. .sp 1P
  1733. .LP
  1734. 3.3.3.3.2
  1735.     \fIError procedures\fR 
  1736. .sp 9p
  1737. .RT
  1738. .PP
  1739. A Data PDU with a length indicator different from hexadecimal \*Q01\*U 
  1740. and/or with less than three octets shall be discarded and the physical 
  1741. network connection shall be cleared. 
  1742. .RT
  1743. .sp 1P
  1744. .LP
  1745. 3.4
  1746.     \fITerminals connected to an ISDN\fR 
  1747. .sp 9p
  1748. .RT
  1749. .PP
  1750. See Recommendation T.90.
  1751. .RT
  1752. .sp 2P
  1753. .LP
  1754. \fB4\fR     \fBInterworking between networks\fR 
  1755. .sp 1P
  1756. .RT
  1757. .PP
  1758. 4.1
  1759. It is the responsibility of Administrations to decide in which network(s) 
  1760. the telematic services are to be provided. 
  1761. .sp 9p
  1762. .RT
  1763. .PP
  1764. 4.2
  1765. Four possibilities are considered below:
  1766. .LP
  1767.     a)
  1768.     Terminals connected to a circuit switched public data
  1769. network\ (CSPDN);
  1770. .LP
  1771.     b)
  1772.     Terminals connected to a packet switched public data
  1773. network\ (PSPDN);
  1774. .LP
  1775.     c)
  1776.     Terminals connected to a public switched telephone
  1777. network\ (PSTN);
  1778. .LP
  1779.     d)
  1780.     Terminals connected to an integrated services digital
  1781. network (ISDN).
  1782. .PP
  1783. 4.3
  1784. Interworking between telematic terminals connected to any
  1785. network must be possible.
  1786. .PP
  1787. 4.4
  1788. International interworking between telematic terminals shall
  1789. preferably take place between networks of the same type when these networks 
  1790. are provided by both countries involved. 
  1791. .PP
  1792. 4.5
  1793. In the case of international interworking between telematic
  1794. terminals connected to dissimilar networks, Recommendation\ X.300 shall apply.
  1795. .PP
  1796. The interworking between CSPDNs and PSPDNs is described in
  1797. Recommendation\ X.82 (Detailed arrangements for interworking between CSPDNs 
  1798. and PSPDNs based on Recommendation\ T.70). 
  1799. .LP
  1800. \fB5\fR     \fBTransport layer procedure\fR 
  1801. .sp 1P
  1802. .RT
  1803. .sp 2P
  1804. .LP
  1805. 5.1
  1806.     \fITransport functions\fR 
  1807. .sp 1P
  1808. .RT
  1809. .sp 1P
  1810. .LP
  1811. 5.1.1
  1812.     \fIGeneral\fR 
  1813. .sp 9p
  1814. .RT
  1815. .PP
  1816. 5.1.1.1
  1817. The transport layer will perform all those functions that are necessary 
  1818. to bridge the gap between the services provided by the network layer and 
  1819. the services needed by the 
  1820. session layer
  1821. . Therefore, the functions performed are dependent on two criteria: the 
  1822. services provided by the 
  1823. underlying network layer and the services required by the session layer.
  1824. .sp 9p
  1825. .RT
  1826. .PP
  1827. 5.1.1.2
  1828. It is the responsibility of the transport service user to
  1829. select a given quality of service, which may imply the use of certain
  1830. transport layer functions such as:
  1831. .LP
  1832.     a)
  1833.     establishment of a transport connection
  1834. .LP
  1835.     \(em
  1836.     transport connection
  1837. identification
  1838. .LP
  1839.     \(em
  1840.     transport connection multiplexing;
  1841. .LP
  1842.     b)
  1843.     data transfer
  1844. .LP
  1845.     \(em
  1846.     sequence control
  1847. .LP
  1848.     \(em
  1849.     error detection
  1850. .LP
  1851.     \(em
  1852.     error recovery
  1853. .LP
  1854.     \(em
  1855.     segmenting and reassembling
  1856. .LP
  1857.     \(em
  1858.     flow control
  1859. .LP
  1860.     \(em
  1861.     purge;
  1862. .LP
  1863.     c)
  1864.     termination of a transport connection.
  1865. .PP
  1866. \fINote\fR \ \(em\ Not all of the above functions will be available in 
  1867. the basic transport service (see \(sc\ 5.1.3). 
  1868. .bp
  1869. .sp 2P
  1870. .LP
  1871. 5.1.2
  1872.     \fITransport protocol classes\fR 
  1873. .sp 1P
  1874. .RT
  1875. .PP
  1876. 5.1.2.1
  1877. Transport layer functions are grouped (for ease of negotiation) into a 
  1878. hierarchical system of transport protocol classes whereby classes 
  1879. occupying superior positions in the hierarchy implement functions of the
  1880. lower classes together with the optional functions identified for their own
  1881. class.
  1882. .sp 9p
  1883. .RT
  1884. .PP
  1885. 5.1.2.2
  1886. During transport connection establishment the use of a given
  1887. transport protocol and optional functions should be negotiated according to
  1888. the following rules:
  1889. .LP
  1890.     \(em
  1891.     the calling terminal indicates the transport protocol class
  1892. and (if applicable) the optional functions required;
  1893. .LP
  1894.     \(em
  1895.     the called terminal indicates the transport protocol class
  1896. and (if applicable) the optional functions that it is willing to
  1897. support;
  1898. .LP
  1899.     \(em
  1900.     all parameters to be used in the transport connection must be
  1901. explicity indicated, otherwise default values will apply.
  1902. .PP
  1903. 5.1.2.3
  1904. The basic transport service described here is fulfilled by a
  1905. protocol denoted in Recommendation\ X.224 as transport protocol class\ 0.
  1906. That protocol class is compatible with Recommendation\ T.70. In the event
  1907. of a discrepancy between transport protocol class\ 0 as described in
  1908. Recommendation\ X.224 and Recommendation\ T.70, the latter takes precedence.
  1909. .sp 2P
  1910. .LP
  1911. 5.1.3
  1912.     \fIThe basic transport service (TS)\fR 
  1913. .sp 1P
  1914. .RT
  1915. .PP
  1916. 5.1.3.1
  1917. A limited set of transport layer functions is defined for a
  1918. basic transport service. The basic transport service is provided by transport 
  1919. layer functions which are performed by 
  1920. \fItransport layer protocol\fR 
  1921. \fIelements\fR .
  1922. .sp 9p
  1923. .RT
  1924. .PP
  1925. 5.1.3.2
  1926. Transport protocol data units (TPDUs) carrying transport
  1927. service (TS) user information or control information are called \fIblocks\fR .
  1928. .PP
  1929. 5.1.3.3 
  1930. Transport layer block types are as follows:
  1931. .LP
  1932.     a)
  1933.     transport connection request (TCR) block;
  1934. .LP
  1935.     b)
  1936.     transport connection accept\fR (TCA) block;
  1937. .LP
  1938.     c)
  1939.     transport connection clear (TCC) block;
  1940. .LP
  1941.     d)
  1942.     transport data (TDT) block;
  1943. .LP
  1944.     e)
  1945.     transport block reject (TBR) block.
  1946. .PP
  1947. 5.1.3.4
  1948. The TCR and TCA blocks are used to indicate the protocol class,
  1949. and optional functions, applying to a transport connection. The TCC\ block is
  1950. used to indicate the reason for refusing a connection establishment. The TDT
  1951. block carries information of the transport service user. The TBR block 
  1952. is used to report procedure errors to the remote terminal. 
  1953. .sp 2P
  1954. .LP
  1955. 5.1.4
  1956.     \fITransport layer functions\fR 
  1957. .sp 1P
  1958. .RT
  1959. .PP
  1960. 5.1.4.1
  1961. Basic class functions and associated transport layer protocol elements, 
  1962. i.e.\ blocks, include: 
  1963. .sp 9p
  1964. .RT
  1965. .LP
  1966.     a)
  1967.     transport connection establishment, transport connection
  1968. identification, optional extended addressing and optional
  1969. transport data block size negotiation (TCR, TCA and\ TCC
  1970. blocks);
  1971. .LP
  1972.     b)
  1973.     data delimitation, segmentation/reassembling of arbitrarily
  1974. long transport service data units (TSDU). These are contained
  1975. within TDT\ blocks. The end of a TSDU is indicated by a TSDU end
  1976. mark in the last data block;
  1977. .LP
  1978.     c)
  1979.     detection and indication of procedural errors
  1980. (TBR\ block).
  1981. .PP
  1982. 5.1.4.2
  1983. Other characteristics of the basic transport service are:
  1984. .LP
  1985.     a)
  1986.     maintenance of TSDU integrity;
  1987. .LP
  1988.     b)
  1989.     overflow: if the user cannot absorb new data and if the
  1990. appropriate buffers are not available, flow control is performed
  1991. at the network/link layer as appropriate;
  1992. .LP
  1993.     c)
  1994.     error: no mechanism is provided within the transport layer
  1995. to facilitate recovery from detected errors. Where such errors
  1996. are detected the user of the transport service should be
  1997. informed so that appropriate recovery action may be taken.
  1998. .bp
  1999. .LP
  2000. 5.2
  2001.     \fIDescription of connection establishment and termination\fR 
  2002. \fIprocedures\fR 
  2003. .sp 1P
  2004. .RT
  2005. .sp 2P
  2006. .LP
  2007. 5.2.1
  2008.     \fIGeneral\fR 
  2009. .sp 1P
  2010. .RT
  2011. .PP
  2012. 5.2.1.1
  2013. The transport layer connection establishment and termination
  2014. procedures shall also be used for negotiating transport protocol class 
  2015. and, if applicable, optional transport connection functions. 
  2016. .sp 9p
  2017. .RT
  2018. .PP
  2019. 5.2.1.2
  2020. For the basic transport service, means are provided to
  2021. establish
  2022. a transport connection using a TCR\ block and a TCA\ block. This exchange
  2023. provides:
  2024. .LP
  2025.     a)
  2026.     a way to negotiate options;
  2027. .LP
  2028.     b)
  2029.     a transport connection identification. The transport
  2030. connection is identified by use of cross\(hyreferences. Each end of
  2031. the connection is responsible for selecting a suitable transport
  2032. connection identifier.
  2033. .PP
  2034. 5.2.1.3
  2035. This mechanism also provides an identification of the transport
  2036. connection independent of any network connection identification and therefore 
  2037. provides independence from the life of the network connection. The binary 
  2038. value\ 0 should not be used as an identifier. The use of such references for
  2039. reconnection requires further definition.
  2040. .sp 2P
  2041. .LP
  2042. 5.2.2
  2043.     \fITransport connection request (TCR) block\fR 
  2044. .sp 1P
  2045. .RT
  2046. .PP
  2047. 5.2.2.1
  2048. The calling terminal shall indicate a transport connection
  2049. request by transferring a TCR\ block to the remote terminal. The TCR\ block
  2050. includes the transport functions (e.g.\ source reference, class, and optional
  2051. functions) for negotiation of the characteristics of the transport connection 
  2052. being established. 
  2053. .sp 9p
  2054. .RT
  2055. .sp 2P
  2056. .LP
  2057. 5.2.3
  2058.     \fITransport connection accept (TCA) block\fR 
  2059. .sp 1P
  2060. .RT
  2061. .PP
  2062. 5.2.3.1
  2063. The called terminal shall indicate its acceptance of the
  2064. transport connection by transferring a TCA\ block to the remote terminal. The
  2065. TCA\ block includes the transport parameters applying to the connection 
  2066. and to be used by the calling terminal. 
  2067. .sp 9p
  2068. .RT
  2069. .PP
  2070. 5.2.3.2
  2071. If a terminal receives the request for an optional TDT block
  2072. size it may either:
  2073. .LP
  2074.     \(em
  2075.     indicate its support by reproducing the requested value
  2076. in the TCA\ block;
  2077. .LP
  2078.     \(em
  2079.     request in the TCA block the use of a shorter allowable
  2080. TDT\ block. The calling side either accepts this size by sending
  2081. the first TDT\ block or disconnects the network connection;
  2082. .LP
  2083.     \(em
  2084.     not accept the requested TDT block size parameter value by
  2085. sending a TCA\ block without a TDT\ block size parameter.
  2086. Therefore, the standardized TDT\ block size will apply.
  2087. .PP
  2088. A TCR requesting an optional TDT block size not supported by
  2089. the called side should not be answered with\ TBR.
  2090. .sp 2P
  2091. .LP
  2092. 5.2.4
  2093.     \fITransport connection clear (TCC) block\fR 
  2094. .sp 1P
  2095. .RT
  2096. .PP
  2097. 5.2.4.1
  2098. If a transport connection cannot be established, the called
  2099. terminal shall respond to the TCR\ block with a TCC\ block. The clearing cause
  2100. shall indicate why the connection was not accepted.
  2101. .sp 9p
  2102. .RT
  2103. .PP
  2104. It is up to the calling side whether the receipt of a TCC will
  2105. cause complete disconnection or whether a new TCR with a parameter different
  2106. from the first one will be sent (e.g.\ another extended transport layer
  2107. address). In order to allow for subsequent TCRs, the sender of TCC may 
  2108. provide in the optional parameter field an appropriate parameter and associated 
  2109. value to indicate that another TCR is invited. The new optional parameter 
  2110. and its 
  2111. associated value(s) are for further study.
  2112. .PP
  2113. \fINote\fR \ \(em\ There is no explicit transport connection termination
  2114. procedure in this Recommendation. Therefore, the lifetime of the transport
  2115. connection is directly correlated to the lifetime of the supporting network
  2116. connection.
  2117. .RT
  2118. .sp 2P
  2119. .LP
  2120. 5.2.5
  2121.     \fITransport connection collision\fR 
  2122. .sp 1P
  2123. .RT
  2124. .PP
  2125. 5.2.5.1
  2126. If the calling terminal receives a TCR block, it shall transfer a TBR\ 
  2127. block to notify the called terminal of the procedure error (see 
  2128. Annex\ B).
  2129. .bp
  2130. .sp 9p
  2131. .RT
  2132. .sp 2P
  2133. .LP
  2134. 5.2.6
  2135.     \fIExtended addressing\fR 
  2136. .sp 1P
  2137. .RT
  2138. .PP
  2139. 5.2.6.1
  2140. The extended addressing capability may be used to address
  2141. terminals in a multiterminal configuration.
  2142. .sp 9p
  2143. .RT
  2144. .PP
  2145. The extension addresses for called and calling terminals are
  2146. optional parameters to TCR and TCA. The use of the calling extension address
  2147. is for further study.
  2148. .PP
  2149. 5.2.6.2
  2150. The receiving terminal shall respond with a TCA according to
  2151. Table\ 1/T.70.
  2152. .ce
  2153. \fBH.T. [T1.70]\fR 
  2154. .ce
  2155. TABLEAU\ 1/T.70
  2156. .ps 9
  2157. .vs 11
  2158. .nr VS 11
  2159. .nr PS 9
  2160. .TS
  2161. center box;
  2162. cw(72p) | cw(78p) sw(78p) , ^  | c | c.
  2163. Received TCR    Receiver reaction
  2164.      {
  2165. Multi\(hyterminal
  2166. with extended addressing | ua\d\u)\d
  2167.  }    Stand\(hyalone terminal
  2168. _
  2169. .T&
  2170. lw(72p) | cw(78p) | cw(78p) .
  2171. Without extended addressing     {
  2172. Send TCA
  2173. with extended addressing
  2174.  }     {
  2175. Send TCA
  2176. without extended addressing
  2177.  }
  2178. _
  2179. .T&
  2180. lw(72p) | cw(78p) | cw(78p) .
  2181. With extended addressing     {
  2182. Send TCA
  2183. with extended addressing | ub\d\u)\d
  2184.  }     {
  2185. Send TCA
  2186. without extended addressing
  2187.  }
  2188. .TE
  2189. .LP
  2190.  
  2191. \ua\d\u)\d
  2192. Multi\(hyterminal configuration, with capability for extended
  2193. addressing.
  2194. .LP
  2195. \ub\d\u)\d
  2196. If the called terminal is occupied or out of order, the call
  2197. should be routed to a default terminal or mailbox. The sender will then be
  2198. informed of the routing by the extension address of the connected terminal. The receiver of TCR may also in this case react by sending TCC.
  2199. .nr PS 9
  2200. .RT
  2201. .ad r
  2202. \fBTable 1/T.70 [T1.70], p.\fR 
  2203. .sp 1P
  2204. .RT
  2205. .ad b
  2206. .RT
  2207. .LP
  2208. .sp 3
  2209. .PP
  2210. 5.2.6.3
  2211. The calling terminal may, when receiving a called terminal
  2212. address in the TCA, act as specified in Table\ 2/T.70.
  2213. .ce
  2214. \fBH.T. [T2.70]\fR 
  2215. .ce
  2216. TABLE\ 2/T.70
  2217. .ps 9
  2218. .vs 11
  2219. .nr VS 11
  2220. .nr PS 9
  2221. .TS
  2222. center box;
  2223. cw(72p) | cw(56p) sw(50p) sw(50p) , ^  | c s s 
  2224. ^  | c | c | c.
  2225. Sent TCR    Calling terminal reaction
  2226.     TCA received with:    No extended  addressing    Correct extended  addressing    Incorrect extended addressing
  2227. _
  2228. .T&
  2229. lw(72p) | cw(56p) | cw(100p) .
  2230. Without extended addressing    OK    Neglect extension  (See Note)
  2231. _
  2232. .T&
  2233. lw(72p) | cw(56p) | cw(50p) | cw(50p) .
  2234. With extended addressing    \ua\d\u)\d    OK    \ua\d\u)\d
  2235. .TE
  2236. .LP
  2237. \ua\d\u)\d\ Reaction left to the discretion of the calling terminal.
  2238. .LP
  2239. \fINote\fR
  2240. \ \(em\ Terminal complying with the 1980\(hy1984 version of Recommendation T.70 may react by releasing the network connection.
  2241. .nr PS 9
  2242. .RT
  2243. .ad r
  2244. \fBTable 2/T.70 [T2.70], p.\fR 
  2245. .sp 1P
  2246. .RT
  2247. .ad b
  2248. .RT
  2249. .LP
  2250. .bp
  2251. .LP
  2252. 5.3
  2253.     \fIDescription of\fR \fIdata transfer procedures\fR 
  2254. .sp 1P
  2255. .RT
  2256. .sp 2P
  2257. .LP
  2258. 5.3.1
  2259.     \fIGeneral\fR 
  2260. .sp 1P
  2261. .RT
  2262. .PP
  2263. 5.3.1.1
  2264. The data transfer procedure described in the following
  2265. subsections applies only when the transport layer is in the data transfer
  2266. phase, i.e.\ after completion of transport connection establishment and 
  2267. prior to clearing. 
  2268. .sp 9p
  2269. .RT
  2270. .PP
  2271. \fINote\fR \ \(em\ When a connection is cleared, transport data blocks 
  2272. may be discarded. Hence it is left to the transport service user to define 
  2273. protocols able to cope with the various possible situations that may occur.
  2274. .sp 2P
  2275. .LP
  2276. 5.3.2
  2277.     \fITransport data block (TDT) length\fR 
  2278. .sp 1P
  2279. .RT
  2280. .PP
  2281. 5.3.2.1
  2282. The standard maximum TDT block length to be supported by all
  2283. terminals is 128\ octets including the data block header octets. However, the
  2284. TDT\ block length may be restricted to a lower value when the TDT\ block is
  2285. concatenated with other TDT\ blocks (see \(sc\ 5.5.3).
  2286. .sp 9p
  2287. .RT
  2288. .PP
  2289. 5.3.2.2
  2290. Other maximum data field lengths may be supported in
  2291. conjunction with an optional TDT\ block size negotiation connection function
  2292. (see \(sc\(sc\ 5.5.4.3 and\ 5.5.5.3). Optional maximum data field lengths 
  2293. shall be 
  2294. chosen from the following:\ 256, 512, 1024 and\ 2048\ octets. If the requested
  2295. optional TDT\ block size cannot be supported, a shorter allowable TDT\ 
  2296. block size must be selected (see \(sc\ 5.2.3.2). 
  2297. .PP
  2298. The agreed maximum TDT block size should be aimed at for
  2299. TDT\ blocks having the TSDU end mark set to\ 0 and a number of octets less 
  2300. than the agreed maximum shall not cause the receiving transport entity 
  2301. to reject 
  2302. this TDT\ block.
  2303. .sp 2P
  2304. .LP
  2305. 5.3.3
  2306.     \fITransport service data unit (TSDU)\fR \fIend\fR 
  2307. .sp 1P
  2308. .RT
  2309. .PP
  2310. 5.3.3.1
  2311. The 
  2312. \fITSDU end mark\fR is used to preserve the integrity of the TSDU. The 
  2313. TSDU end mark is set to binary\ 1 in the last TDT\ data block 
  2314. carrying information related to a certain TSDU. Exceptionally, this
  2315. TDT\ block may be sent without carrying user information in order to allow
  2316. for an immediate termination of a TSDU in certain error conditions.
  2317. .sp 9p
  2318. .RT
  2319. .PP
  2320. In case of a TSDU that comprises a single TDT\ block the TSDU end mark 
  2321. is also set to\ 1. In all other cases the TSDU end mark is set to zero. 
  2322. .sp 2P
  2323. .LP
  2324. 5.4
  2325.     \fITreatment of procedure errors\fR 
  2326. .sp 1P
  2327. .RT
  2328. .PP
  2329. 5.4.1
  2330. A terminal shall send a TBR block to the remote terminal to
  2331. report the receipt of an invalid or not implemented block (if not explicitly
  2332. specified otherwise in this Recommendation). During the establishment of a
  2333. transport connection, terminals shall not send a TBR\ block upon the receipt
  2334. of a TCR\ block whose parameters or parameter values are invalid or not
  2335. implemented. In this case, terminals shall act as if no errors have occurred
  2336. and send the appropriate response (if any).
  2337. .sp 9p
  2338. .RT
  2339. .PP
  2340. A terminal receiving a TBR block shall take appropriate recovery   action.
  2341. .PP
  2342. \fINote\ 1\fR \ \(em\ A TBR whether invalid or valid shall not be answered by
  2343. sending a TBR\ block.
  2344. .PP
  2345. \fINote\ 2\fR \ \(em\ Terminals complying with the Recommendation\ T.70 
  2346. version of the 1981\(hy1984 study period may react to all of the above 
  2347. indicated 
  2348. conditions by sending\ TBR.
  2349. .PP
  2350. \fINote\ 3\fR \ \(em\ The definition of invalid block/parameter, etc. is 
  2351. provided by the state transition tables (see Annex\ B). 
  2352. .PP
  2353. \fINote\ 4\fR \ \(em\ A TCR of which the PV of the TPDU size parameter is less
  2354. than 07 (which is the basic length of the transport block size) shall be
  2355. considered as an invalid TPDU.
  2356. .PP
  2357. \fINote\ 5\fR \ \(em\ In the states 1.1 for the calling side and 2.1 for the
  2358. calling and called side the terminal may react either by sending TBR or by
  2359. releasing the network connection.
  2360. .PP
  2361. \fIAttention\fR  | \ The state tables and state transition diagrams have 
  2362. to be read according to Notes\ 4 and\ 5 above. 
  2363. .bp
  2364. .RT
  2365. .LP
  2366. 5.5
  2367.     \fIFormats\fR 
  2368. .sp 1P
  2369. .RT
  2370. .sp 2P
  2371. .LP
  2372. 5.5.1
  2373.     \fIGeneral\fR 
  2374. .sp 1P
  2375. .RT
  2376. .PP
  2377. 5.5.1.1
  2378. Transport protocol data units (TPDUs)
  2379. carrying
  2380. transport service (TS) user
  2381. information or control information are called \fIblocks\fR (see \(sc\ 5.1.3). 
  2382. All 
  2383. blocks contain an integral number of octets.
  2384. .sp 9p
  2385. .RT
  2386. .PP
  2387. 5.5.1.2
  2388. Bits of an octet are numbered 8\ to\ 1 where bit 1 is the low
  2389. order bit and is transmitted first. Octets of a block are consecutively
  2390. numbered starting from\ 1 and are transmitted in this order.
  2391. .PP
  2392. When consecutive octets are used to represent a binary number, the lower 
  2393. octet has the most significant value. 
  2394. .PP
  2395. 5.5.1.3
  2396. \fITDT block(s)\fR are used to transfer a transport service data
  2397. unit (TSDU) transparently whilst maintaining the structure of the latter by
  2398. means of the TSDU end mark.
  2399. .PP
  2400. 5.5.1.4
  2401. \fIControl blocks\fR (TCR, TCA, TCC, TBR) are used to control the
  2402. transport protocol functions, including optional functions.
  2403. .PP
  2404. 5.5.1.5
  2405. A parameter field is present in all control blocks within the
  2406. basic transport service to indicate optional functions. The parameter field
  2407. contains one or more parameter elements. The first octet of each parameter
  2408. element contains a parameter code to indicate the function(s) requested.
  2409. .PP
  2410. The general coding structure is shown in Figure 5/T.70.
  2411. .LP
  2412. .rs
  2413. .sp 20P
  2414. .ad r
  2415. \fBFigure 5/T.70 p.\fR 
  2416. .sp 1P
  2417. .RT
  2418. .ad b
  2419. .RT
  2420. .PP
  2421. 5.5.1.6
  2422. The parameter code field is binary coded and, without
  2423. extension, provides for a maximum of 255\ para
  2424. meters. Parameter code 11111111 is reserved for 
  2425. extension of the parameter code
  2426. . The extension
  2427. mechanism is for further study.
  2428. .PP
  2429. Octet 2 indicates the length, in octets, of the parameter value
  2430. field. The parameter field length is binary coded and bit\ 1 is the low order
  2431. bit of this indicator.
  2432. .PP
  2433. Octet 3 and subsequent octets contain the value of the parameter
  2434. identified in the parameter code field. The coding of the parameter value 
  2435. field is dependent on the function being requested. 
  2436. .bp
  2437. .RT
  2438. .sp 2P
  2439. .LP
  2440. 5.5.2
  2441.     \fIStructure of transport control and transport data blocks\fR 
  2442. .sp 1P
  2443. .RT
  2444. .PP
  2445. 5.5.2.1
  2446. Figure 6/T.70 illustrates the general structure of transport
  2447. layer blocks. A summary of transport layer blocks is given in Figure\ 7/T.70.
  2448. .sp 9p
  2449. .RT
  2450. .LP
  2451. .rs
  2452. .sp 8P
  2453. .ad r
  2454. \fBFigure 6/T.70, p.\fR 
  2455. .sp 1P
  2456. .RT
  2457. .ad b
  2458. .RT
  2459. .LP
  2460. .rs
  2461. .sp 23P
  2462. .ad r
  2463. \fBFigure 7/T.70, p.\fR 
  2464. .sp 1P
  2465. .RT
  2466. .ad b
  2467. .RT
  2468. .sp 2P
  2469. .LP
  2470. 5.5.2.2
  2471.     \fILength indicator (LI) field\fR 
  2472. .sp 1P
  2473. .RT
  2474. .sp 1P
  2475. .LP
  2476. 5.5.2.2.1\ \ Octet 1 contains the 
  2477. length indicator (LI)
  2478. . The value
  2479. of this indicator is a binary number that represents the length in octets of
  2480. the control block (including parameters) and the header length in octets of
  2481. data blocks (excluding any subsequent user information). In both cases this
  2482. length does not include octet\ 1.
  2483. .sp 9p
  2484. .RT
  2485. .LP
  2486. 5.5.2.2.2\ \ The basic LI value shall be restricted to\ 127 (i.e.,\ a binary
  2487. value of 01111111). The use of higher LI\ values and the use of the binary 
  2488. value 11111111 for extension purposes is for further study. 
  2489. .sp 2P
  2490. .LP
  2491. 5.5.2.3
  2492.     \fIBlock type field\fR 
  2493. .sp 1P
  2494. .RT
  2495. .sp 1P
  2496. .LP
  2497. 5.5.2.3.1\ \ Octet 2 contains the block type code. Bits\ 1 to 4 of
  2498. octet\ 2 are set to\ 0 for all transport layer blocks currently defined. It is
  2499. for further study to determine whether or not bits\ 1 to\ 4 are required for
  2500. future extension to the range of transport layer blocks currently defined or
  2501. are used for other functions.
  2502. .bp
  2503. .sp 9p
  2504. .RT
  2505. .sp 2P
  2506. .LP
  2507. 5.5.2.4
  2508.     \fIFunctional code field\fR 
  2509. .sp 1P
  2510. .RT
  2511. .sp 1P
  2512. .LP
  2513. 5.5.2.4.1\ \ Octet 3 and subsequent octets contain functional codes in a
  2514. fixed format as per the block type (see Figure\ 7/T.70).
  2515. .sp 9p
  2516. .RT
  2517. .sp 2P
  2518. .LP
  2519. 5.5.2.5
  2520.     \fIParameter or TSDU field\fR 
  2521. .sp 1P
  2522. .RT
  2523. .sp 1P
  2524. .LP
  2525. 5.5.2.5.1\ \ A parameter field or a data field containing transport service
  2526. (TS) user data may optionally follow the functional code field.
  2527. .sp 9p
  2528. .RT
  2529. .sp 2P
  2530. .LP
  2531. 5.5.3
  2532.     \fIConcatenation\fR 
  2533. .sp 1P
  2534. .RT
  2535. .PP
  2536. 5.5.3.1
  2537. Concatenation of transport control and/or transport data blocks is currently 
  2538. not applicable to this Recommendation. However, where 
  2539. concatenation is used in the future, the arrangement shown in Figure\ 8/T.70
  2540. would apply.
  2541. .sp 9p
  2542. .RT
  2543. .LP
  2544. .rs
  2545. .sp 36P
  2546. .ad r
  2547. \fBFigure 8/T.70, p.\fR 
  2548. .sp 1P
  2549. .RT
  2550. .ad b
  2551. .RT
  2552. .LP
  2553. .bp
  2554. .sp 2P
  2555. .LP
  2556. 5.5.4
  2557.     \fITransport connection request (TCR) block format\fR 
  2558. .sp 1P
  2559. .RT
  2560. .PP
  2561. 5.5.4.1
  2562. Figure 9/T.70 illustrates the format of the TCR block.
  2563. .sp 9p
  2564. .RT
  2565. .LP
  2566. .rs
  2567. .sp 28P
  2568. .ad r
  2569. \fBFigure 9/T.70 p.\fR 
  2570. .sp 1P
  2571. .RT
  2572. .ad b
  2573. .RT
  2574. .sp 1P
  2575. .LP
  2576. 5.5.4.2
  2577.     \fIParameters for extended addressing\fR 
  2578. .sp 9p
  2579. .RT
  2580. .PP
  2581. Separate parameters are provided for the indication of called and calling 
  2582. extension addresses. The coding of these parameters is shown in 
  2583. Figure\ 10/T.70. The setting of bit\ 8 for extended addressing should be 
  2584. ignored by the transport layer. 
  2585. .PP
  2586. The use of more than one called extension address is for further
  2587. study.
  2588. .RT
  2589. .LP
  2590. .rs
  2591. .sp 13P
  2592. .ad r
  2593. \fBFigure 10/T.70, p.\fR 
  2594. .sp 1P
  2595. .RT
  2596. .ad b
  2597. .RT
  2598. .LP
  2599. .bp
  2600. .sp 1P
  2601. .LP
  2602. 5.5.4.3
  2603.     \fIParameter for transport data block size negotiation\fR 
  2604. .sp 9p
  2605. .RT
  2606. .PP
  2607. This parameter defines the proposed maximum transport data block size (in 
  2608. octets including the transport data block header) to be used over 
  2609. the requested transport connection. The coding of this parameter is shown in
  2610. Figure\ 11/T.70.
  2611. .RT
  2612. .LP
  2613. .rs
  2614. .sp 14P
  2615. .ad r
  2616. \fBFigure 11/T.70, p.\fR 
  2617. .sp 1P
  2618. .RT
  2619. .ad b
  2620. .RT
  2621. .sp 2P
  2622. .LP
  2623. 5.5.5
  2624.     \fITransport connection accept (TCA) block format\fR 
  2625. .sp 1P
  2626. .RT
  2627. .PP
  2628. 5.5.5.1
  2629. Figure 12/T.70 illustrates the format of the TCA block.
  2630. .sp 9p
  2631. .RT
  2632. .LP
  2633. .rs
  2634. .sp 27P
  2635. .ad r
  2636. \fBFigure 12/T.70 p.\fR 
  2637. .sp 1P
  2638. .RT
  2639. .ad b
  2640. .RT
  2641. .LP
  2642. .bp
  2643. .sp 1P
  2644. .LP
  2645. 5.5.5.2 
  2646.     \fIParameters for extended addressing\fR 
  2647. .sp 9p
  2648. .RT
  2649. .PP
  2650. See \(sc\ 5.5.4.2.
  2651. .RT
  2652. .sp 1P
  2653. .LP
  2654. 5.5.5.3
  2655.     \fIParameter for transport data block size negotiation\fR 
  2656. .sp 9p
  2657. .RT
  2658. .PP
  2659. See \(sc\ 5.5.4.3. The parameter value shall be equal to or less
  2660. than the value specified in the TCR block.
  2661. .RT
  2662. .sp 2P
  2663. .LP
  2664. 5.5.6
  2665.     \fITransport connection clear (TCC) block format\fR 
  2666. .sp 1P
  2667. .RT
  2668. .PP
  2669. 5.5.6.1
  2670. Figure 13/T.70 illustrates the format of the TCC block.
  2671. .sp 9p
  2672. .RT
  2673. .LP
  2674. .rs
  2675. .sp 43P
  2676. .ad r
  2677. \fBFigure 13/T.70, p.\fR 
  2678. .sp 1P
  2679. .RT
  2680. .ad b
  2681. .RT
  2682. .LP
  2683. .bp
  2684. .sp 1P
  2685. .LP
  2686. 5.5.6.2
  2687.     \fIParameter for additional clearing information\fR 
  2688. .sp 9p
  2689. .RT
  2690. .PP
  2691. This parameter is provided to allow additional information
  2692. relating to the clearing of the connection. The coding of this parameter is
  2693. given in Figure\ 14/T.70 below.
  2694. .RT
  2695. .LP
  2696. .rs
  2697. .sp 12P
  2698. .ad r
  2699. \fBFigure 14/T.70 p.\fR 
  2700. .sp 1P
  2701. .RT
  2702. .ad b
  2703. .RT
  2704. .sp 2P
  2705. .LP
  2706. 5.5.7
  2707.     \fITransport block reject (TBR) block format\fR 
  2708. .sp 1P
  2709. .RT
  2710. .PP
  2711. 5.5.7.1
  2712. Figure 15/T.70 illustrates the format of the TBR block.
  2713. .sp 9p
  2714. .RT
  2715. .LP
  2716. .rs
  2717. .sp 28P
  2718. .ad r
  2719. \fBFigure 15/T.70, p.\fR 
  2720. .sp 1P
  2721. .RT
  2722. .ad b
  2723. .RT
  2724. .LP
  2725. .bp
  2726. .sp 1P
  2727. .LP
  2728. 5.5.7.2
  2729.     \fIRejected block parameter\fR (mandatory)
  2730. .sp 9p
  2731. .RT
  2732. .PP
  2733. This parameter is used to indicate the bit pattern of the rejected block 
  2734. up to and including the octet that caused the rejection. Only the first 
  2735. detected procedural error or parameter, which cannot be acted upon, shall 
  2736. be 
  2737. indicated by this method. The coding of this parameter is given in
  2738. Figure\ 16/T.70.
  2739. .RT
  2740. .LP
  2741. .rs
  2742. .sp 11P
  2743. .ad r
  2744. \fBFigure 16/T.70 p.\fR 
  2745. .sp 1P
  2746. .RT
  2747. .ad b
  2748. .RT
  2749. .sp 2P
  2750. .LP
  2751. 5.5.8
  2752.     \fITransport data block (TDT) format\fR 
  2753. .sp 1P
  2754. .RT
  2755. .PP
  2756. 5.5.8.1
  2757. Figure 17/T.70 illustrates the format of the TDT block.
  2758. .sp 9p
  2759. .RT
  2760. .LP
  2761. .rs
  2762. .sp 18P
  2763. .ad r
  2764. \fBFigure 17/T.70 p.\fR 
  2765. .sp 1P
  2766. .RT
  2767. .ad b
  2768. .RT
  2769. .ce 1000
  2770. ANNEX\ A
  2771. .ce 0
  2772. .ce 1000
  2773. (to Recommendation T.70)
  2774. .sp 9p
  2775. .RT
  2776. .ce 0
  2777. .LP
  2778. A.1
  2779.     \fITransport and network service\fR 
  2780. .sp 1P
  2781. .RT
  2782. .PP
  2783. The 
  2784. transport service
  2785. (TS) is provided by the
  2786. transport protocol
  2787. (TP) making use of the services available from the network layer. This 
  2788. Annex also defines the\ TS characteristics which the 
  2789. TS\ users may exploit.
  2790. .PP
  2791. Interactions between TS users and the TS provider take place at the
  2792. two TS access points (TSAP) (see Figures\ A\(hy1/T.70 to A\(hy6/T.70). 
  2793. Information is passed between a TS\ user and a TS\ provider by means of 
  2794. primitives, which 
  2795. may convey parameters.
  2796. .bp
  2797. .PP
  2798. Primitives are abstract representations of interactions. They are
  2799. solely descriptive and do not represent a specification or implementation.
  2800. .PP
  2801. The occurrence of a primitive is a logically instantaneous and
  2802. indivisible event. The event occurs at a logically separate instant,
  2803. which cannot be interrupted by another event. Only primitives of global
  2804. significance are mentioned (having an impact on the remote user).
  2805. .PP
  2806. The following types of primitives are defined:
  2807. .RT
  2808. .LP
  2809.     a)
  2810.     request primitive
  2811. .LP
  2812.     b)
  2813.     indication primitive
  2814. .LP
  2815.     c)
  2816.     response primitive
  2817. .LP
  2818.     d)
  2819.     confirm primitive.
  2820. .PP
  2821. The primitives a) and c) are directed from the service user to the service 
  2822. provider, b) and d) are going in the opposite direction. 
  2823. .PP
  2824. \*QTransport\*U is designated by T, \*QNetwork\*U is designated by N. The
  2825. terms CONNECT, DATA, DISCONNECT as part of a primitive name indicate that
  2826. the primitive is used for establishment, data transfer, release of a
  2827. transport connection
  2828. \ (TC) or 
  2829. network connection
  2830. \ (NC).
  2831. .RT
  2832. .sp 1P
  2833. .LP
  2834.     \fIExamples:\fR 
  2835. .sp 9p
  2836. .RT
  2837. .LP
  2838.     T\(hyCONNECT request
  2839.     request to establish a TC
  2840. .LP
  2841.     T\(hyDATA request
  2842.     request to transmit TS user data
  2843. .LP
  2844.     N\(hyDISCONNECT indication
  2845.     indication that the NC has been released.
  2846. .PP
  2847. The relationship between valid sequences of TS primitives and the appropriate 
  2848. protocol elements is shown in Figures\ A\(hy1/T.70 to A\(hy6/T.70. The 
  2849. sequences of valid 
  2850. network service
  2851. \ (NS) primitives are illustrated in Figures\ A\(hy7/T.70 to A\(hy12/T.70.
  2852. .sp 1P
  2853. .LP
  2854. A.1.1
  2855.     \fITransport service\fR 
  2856. .sp 9p
  2857. .RT
  2858. .PP
  2859. The interactions shown in Figures\ A\(hy1/T.70 to A\(hy6/T.70 are not
  2860. exhaustive.
  2861. .RT
  2862. .sp 1P
  2863. .LP
  2864. A.1.1.1\ \ \fITransport connection establishment\fR 
  2865. .sp 9p
  2866. .RT
  2867. .LP
  2868. .rs
  2869. .sp 19P
  2870. .ad r
  2871. \fBFigures A\(hy1/T.70 and A\(hy2/T.70 p.\fR 
  2872. .sp 1P
  2873. .RT
  2874. .ad b
  2875. .RT
  2876. .LP
  2877. .bp
  2878. .sp 1P
  2879. .LP
  2880. A.1.1.2\ \ \fITransfer phase\fR 
  2881. .sp 9p
  2882. .RT
  2883. .LP
  2884. .rs
  2885. .sp 23P
  2886. .ad r
  2887. \fBFigure A\(hy3/T.70 p.\fR 
  2888. .sp 1P
  2889. .RT
  2890. .ad b
  2891. .RT
  2892. .sp 1P
  2893. .LP
  2894. A.1.1.3\ \ \fITransport service error reporting\fR 
  2895. .sp 9p
  2896. .RT
  2897. .LP
  2898. .rs
  2899. .sp 18P
  2900. .ad r
  2901. \fBFigure A\(hy4/T.70 p.\fR 
  2902. .sp 1P
  2903. .RT
  2904. .ad b
  2905. .RT
  2906. .LP
  2907. .bp
  2908. .sp 1P
  2909. .LP
  2910. A.1.1.4\ \ \fITC release\fR 
  2911. .sp 9p
  2912. .RT
  2913. .PP
  2914. At present only the implicit release of TC is defined (see
  2915. \(sc\ 5.2.4.1 of this Recommendation).
  2916. .RT
  2917. .LP
  2918. .rs
  2919. .sp 17P
  2920. .ad r
  2921. \fBFigures A\(hy5/T.70 and A\(hy6/T.70 p.\fR 
  2922. .sp 1P
  2923. .RT
  2924. .ad b
  2925. .RT
  2926. .sp 1P
  2927. .LP
  2928. A.1.2
  2929.     \fINetwork service\fR 
  2930. .sp 9p
  2931. .RT
  2932. .PP
  2933. Figures A\(hy7/T.70 to A\(hy12/T.70 show the relationships of network
  2934. service\ (NS) primitives at both sides of an\ NC.
  2935. .RT
  2936. .sp 1P
  2937. .LP
  2938. A.1.2.1\ \ \fINetwork connection establishment\fR 
  2939. .sp 9p
  2940. .RT
  2941. .LP
  2942. .rs
  2943. .sp 22P
  2944. .ad r
  2945. \fBFigures A\(hy7/T.70 and A\(hy8/T.70 p.\fR 
  2946. .sp 1P
  2947. .RT
  2948. .ad b
  2949. .RT
  2950. .LP
  2951. .bp
  2952. .sp 1P
  2953. .LP
  2954. A.1.2.2\ \ \fINetwork data transfer\fR 
  2955. .sp 9p
  2956. .RT
  2957. .LP
  2958. .rs
  2959. .sp 12P
  2960. .ad r
  2961. \fBFigure A\(hy9/T.70 p.\fR 
  2962. .sp 1P
  2963. .RT
  2964. .ad b
  2965. .RT
  2966. .sp 1P
  2967. .LP
  2968. A.1.2.3\ \ \fINetwork service error reporting\fR 
  2969. .sp 9p
  2970. .RT
  2971. .LP
  2972. .rs
  2973. .sp 13P
  2974. .ad r
  2975. \fBFigure A\(hy10/T.70 p.\fR 
  2976. .sp 1P
  2977. .RT
  2978. .ad b
  2979. .RT
  2980. .sp 1P
  2981. .LP
  2982. A.1.2.4\ \ \fINetwork connection release\fR 
  2983. .sp 9p
  2984. .RT
  2985. .LP
  2986. .rs
  2987. .sp 13P
  2988. .ad r
  2989. \fBFigures A\(hy11/T.70 and A\(hy12/T.70 p.\fR 
  2990. .sp 1P
  2991. .RT
  2992. .ad b
  2993. .RT
  2994. .LP
  2995. .bp
  2996. .sp 1P
  2997. .LP
  2998. A.2
  2999.     \fIState transition diagrams for the basic\fR 
  3000. \fItransport layer\fR 
  3001. \fIprocedures\fR 
  3002. .sp 9p
  3003. .RT
  3004. .PP
  3005. This part represents detailed state transition diagrams for the
  3006. basic transport procedures.
  3007. .PP
  3008. Two description levels are used:
  3009. .RT
  3010. .LP
  3011.     a)
  3012.     \fIProtocol level\fR 
  3013. .LP
  3014.     This level addresses only the peer to peer protocol activities
  3015. between two transport entities. It identifies the protocol
  3016. state, events [receipt of transport protocol data units (TPDUs)]
  3017. and actions (sending of TPDUs).
  3018. .LP
  3019.     b)
  3020.     \fIDetailed level\fR 
  3021. .LP
  3022.     This level addresses the inter\(hylayer and local activities. It
  3023. identifies the events, actions, conditions and states within
  3024. each of the protocol level states. The inter\(hylayer activities
  3025. are described using the transport service primitives defined in
  3026. the first\ part of this Annex.
  3027. .PP
  3028. \fIExample\fR (see Figure\ A\(hy13/T.70)
  3029. .PP
  3030. For pure illustrative reasons, the example shows a simplified
  3031. description of state 1 (response pending, called side) of the state transition 
  3032. diagram of this Recommendation. The event R\(hyTCR may be answered either 
  3033. by 
  3034. sending the action S\(hyTCA or\ S\(hyTCC.
  3035. .PP
  3036. The events and actions are not interruptable. They will complete
  3037. their transfer irrespective of the occurrence of other events.
  3038. .PP
  3039. The detailed state transition diagrams are given in Figures\ A\(hy14/
  3040. and\ A\(hy15/T.70.
  3041. .RT
  3042. .LP
  3043. .rs
  3044. .sp 31P
  3045. .ad r
  3046. \fBFigure A\(hy13/T.70 p.37\fR 
  3047. .sp 1P
  3048. .RT
  3049. .ad b
  3050. .RT
  3051. .LP
  3052. .bp
  3053. .LP
  3054. .rs
  3055. .sp 47P
  3056. .ad r
  3057. \fBFigure A\(hy14/T.70 p.38\fR 
  3058. .sp 1P
  3059. .RT
  3060. .ad b
  3061. .RT
  3062. .LP
  3063. .bp
  3064. .LP
  3065. .rs
  3066. .sp 47P
  3067. .ad r
  3068. \fBFigure A\(hy15/T.70 p.\fR 
  3069. .sp 1P
  3070. .RT
  3071. .ad b
  3072. .RT
  3073. .LP
  3074. .bp
  3075.